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[57] ABSTRACT 

A system is disclosed for automatically distributmg secured 
versions (*Sys_D_Jcey*) of a file decryption key (Sys__ 
D_Jcey) to a plurality of file users by way of the file's 
security label. The label is defined to contain a plurality of 
Access-Control- En tries Records (ACER's) where each 
ACER includes a respective secured version (*Sys_D_„ 
key*) of the file decryption key. Each such secured version 
(*Sys_D^ey*) is decipherable by a respective ACER 
private key. Each ACER may include respective other data 
such as: 

(a) ACER-unique identifying data for uniquely identify- 
ing the ACER or an associated user, 

(b) decryption algorithm identifying data for identifying 
the decryption process to be used to decrypt the 
encrypted *DArA* portion of the file; and 

(c) special handling code for specifying special handling 
for the code-containing ACER. Ihc label is preferably 
covered by a digital signature but includes an extension 
buffer that is not covered by the digital signature. Users 
who wish to have an ACER of their own added to the 
label may submit add-on requests by writing to the 
extension buffer. 
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CRYPTOGRAPHIC FILE LABELING 
SYSTEM FOR SUPPORTING SECURED 
ACCESS BY MULTIPLE USERS 

BACKGROUND 
1. Field of the Inveatioa 

The inveatioa relates generally to the field of securing 
stored digital data from unauthorized use. 

The invention relates more specifically to the problem of 
providing an easily usable computer system that provides 
features such as automatic data decryption and automatic 
data re-encryption while operating within the coatexl of a 
multi-user operating system. 

The invention relates even more particularly to the prob- 
lem of providing secwely labeled files each with encrypted 
data that is intelligibly accessible to a plurality of authorized 
users. 

2a, Cross Reference to Related Pending Applications 
The following copending U.S. patent appLication(s) is/are 
assigned to the assignee of the present application, is/are 
related to the present application and its/their disclosures 
is/are incorporated herein by reference: 

(A) Ser. No. 08/586,511 [Attorney Docket No. 
SYMA1015] filed Jan. 16, 1996 by W. D. McDonnal et 
al Cohen and entitled, SYSTEM FOR AUTOMATIC 
DECRYPTION OF RLE DATA ON A PER-USE 
BASIS AND AUTOMATIC RE-ENCRYPTION 
WITHIN CONTEXT OF MULTI -THREADED 
OPERAnNG SYSTEM UNDER WHICH APPUCA- 
TIONS RUN IN REAL-TIME. 
2b. Cross Reference to Related Patents 
The disclosures of the following U.S. patent(s) is/are 
incorporated herein by reference: 

(A) U.S. Pat. No. 4,864,616 issued Sep. 5, 1989 to E. W. 
Pond et al and entiUed, CRYPTOGRAPHIC LABEL- 
ING OF ELECTRONICALLY STORED DAFA; and 

(B) U.S. Pat. No. 5,052,040 issued Sep. 24, 1991 to H. W. 
Preston et al and entitled, MULTIPLE USER STORED 
DATA CRYPTOGRAPHIC LABELING SYSTEM 
AND METHOD; and 

(C) U.S. Pat. No. 5,481,701 issued Jan. 2, 1996 to Lloyd. 
L. Chambers IV, and entided, METHOD AND APPA- 
RATUS FOR PERFORMING DIRECT READ OF 
COMPRESSED DATA FILE. 

3. Description of the Related Art 

As knowledge of computers; and as use of computers and 
of digital data proliferates throughout society, the threat 
grows that unauthorized persons will gain useful 
(intelligent) access to confidential, digitized infonnation. 

A wide variety of materials may be stored in the form of 
digitized data and there may be many legitimate reasons for 
keeping in confidence, the information represented by such 
stored data. 

By way of example, stored digital data may represent 
medical records of private patients. The latter records may 
be stored as digital data in a hospital's database computer. 
Each patient may wish to have bis or her medical records 
kept in confidence by a selected one or more doctors. 
However, the hospitaPs database computer may be con- 
nected to a local or wide area communications network 
(LAN or WAN) so that a remotely located physician or 
another authorized person can quickly access the medical 
record of a particular patient when needed, such as in the 
case of a medical emergency. 

For the above example, one or more security measures 
should be taken to maintain the expected confidentiality of 



10 



30 



so 



55 



60 



65 



the medical records by blocking unauthorized persons from 
gaining useful access to these medical records. 

There are many other instances where security is desired. 
By way of further example, the to-be-kept confidential 
information may include private business, and/or private 
financial, data and plans that are digitally recorded internally 
within a portable (e.g., laptop) computer or on a portable 
disk or tape. The to-be-kept confidential information may 
constitute legitimate trade secrets of a company, including 
proprietary vendor and customer fists, technical drawings 
and other expressions of technology know-how digitally 
recorded on a computer-readable medium (e.g., on a mag- 
netically and/or optically encoded digital tape or digital disk 
and/or in nonvolatile random access memory). 

Unauthorized access to the media that stores the data 
representing such digitized information or to the data itself 
may come about in many ways. 

A floppy diskette having the confidential information 
digitally recorded thereon may fall into the hands of a person 
who is not authorized to have such information. Such 
physical possession of the floppy diskette may come about 
either through defiberate misappropriation or by accident. 

An unauthorized person may alternatively gain physical 
entry, either lawfully or unlawfully, into a room in which a 
computer terminal has been inadvertently left turned on with 
the last user still being 'logged-on* or otherwise having 
access rights as far as the operating system (OS) is con- 
cerned. If appropriate security measures arc not invoked in 
such circumstances, the unauthorized intruder may be able 
to gain access to confidential data through the left-on 
terminal. 

Unauthorized access may be otherwise achieved through 
a local or wide area network (LAN or WAN) by someone 
who chances upon a password. 

In each of these or like cases, where an outer ring of 
security can be breached, it is desirable to maintain at least 
one more barrier to useful acquisition of the digitized 
information. To this end, many data security systems rely in 
part or in whole on file data encryption. 

The idea is to keep confidential information in an exclu- 
sively encrypted format as much as possible so that, even if 
the digitized data falls into the wrong hands, it is still secured 
by a private encryption key. 

Unfortunately, useful information is rarely kept in the 
encrypted state forever. 

Sooner or later, one or more authorized users need to 
decrypt the encrypted file data in order to use its data. 

Authentication of authorized users and management of 
passwords or keys becomes a problem when multiple users 
need to be given inteUigent access to the information of one 
or more encrypted files. 

If one password (and/or decryption key) is handed out to 
muh^jle users, the risk of compromise increases additively. 

With each additional authorized user, there comes an 
additional non-zero probability of leakage of the file access 
password (and/or decryption key) directly or indirectly 
through the activities of that added user. The more autho- 
rized users there arc, the higher the probability of leakage of 
the one password/key to an unauthorized user. 

One previously-known security system (U.S. Pat. No. 
4,854,616 of Pond et al) relies on a mixture of keys to reduce 
the risk of compromise. A label is prefixed to each file and 
encrypted separately firom the file using a 'mandatory key' 
(and a checksum). The encryption algorithm is a symmetri- 
cal one, such as exclusive ORring with a key stream. The 
same key is used for both encryption and decryption. 

The label contains auxifiary information needed for 
decrypting the separately encrypted file. 
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At the time of attempted access to the file, the label must affecting the usability of the private user keys of other users, 

first be symmetrically decrypted with the 'mandatory key* Various features in accordance with the invention are listed 

(and the label's chedcsujn). The accessing user must then below. 

present a label-specified mixmre of user/machine identifiers. (1) Private Decrypt of System Key for each User 

The latter act as 'seeds' that produce secondary keys. The 5 One feature in accordance with the invention is that each 

seed-produced secondary keys are needed to decrypt the user utilizes his or her own private user key to unlock data 

attached file. in a corresponding. User's Access-Control-Entrics Record 

The secondary key-generating 'seeds' can include a Pri- (User's ACER) within a file's security label The private 

mary User ID (FID), a Secondary User ID (SID), a machine user key can include a private portion of a public/private key 

configuration (OD), and a Machine ID (MID). Failure to lO pair and/or it can include a password that is privately 

supply all the label-specified mixture of secondary key- possessed by the user. 

generating 'seeds* during a so-called Access Check phase (2) Label-based Distribution of System Key to each User 

results in the user being denied access to the requested file. Another feature in accordance with the invention is that 

A drawback of the Pond security system is that the same the primary access key for unlocking (decrypting) an 

'mandatory key' is given to aU authorized users for decrypt- is encrypted *F1IJE DATA* portion of a given file is distrib- 

ing the file label. A compromise of the 'mandatory key' utedtoauthorizcdusersby way of the attached label portion, 

unlocks the whole of the file label for examination by (3) Label-based Collection of Requests for System Key 

unauthorized entities and thereby reduces the security of the Distribution to Not-yet-authorized Users 

overall system. Another feature in accordance with the invention is that 

Another drawback of the Pond security system arises 20 not-yet-authorized users can submit requests by way of the 

when a labelled file is moved from one machine to another attached label portion for private receipt of the primary 

with proper authorization, and/or the file -holding machine is access key for unlocking (decrypting) a correspondingly 

reconfigured. If the file label calls for presentation of a encrypted* FILE DATA* portion of a given file. To this end, 

specific MID (machine identification code) and/or a specific if the label is covered by a digital signature, an extension 

CID (machine configuration specifier), the file label has to 25 buffer zone is provided in the label for receiving the requests 

be altered to reflect the new machine or configuration each of the not-yct-authorized users and the extension buffer zone 

time a legitimate move is made and/or a machine configu- is not covered by the digital signature, 

ration is altered. This can be difficult to manage in a large (4) Label-based Distribution of Label-use Rights to each 

networked system where files and/or users are routinely User 

moved from one machine to another and machines are 30 Another feature in accordance with the invention is that 

routinely reconfigured. label-use rights (such as the right to modify the label) are 

An improvement over the Pood system is provided in U.S. individually distributed to authorized users by way of the 

Pat. No. 5,052,040 to Preston. The Preston system uses the label. 

same file labelling approach as that of Pond but extends the Other features and aspects of the invention wUl become 

file label to include a user permissions area. Some users are 35 apparent from the below detailed description, 

wanted full read/write access to the file contents while other _ 

Ser.arcgran.edonly.cadaccess.monce^ncryptedPond BRIEF DESCRIPTION OF TOE DRAWINGS 

label and the non-encrypted, user permissions extension are The below detailed description makes reference to the 

both symmetrically (or 'reversibly') encrypted with a DAC- accompanying drawings, in which: 

seeded key stream after the Pond label has been encrypted 40 FIG. L\ is a block diagram showing a previously known, 

with the mandatory key stream. The DAC seed public_key/private_key, asymmetric encryption/ 

(Discretionary Access Control seed) is generated during decryption system; 

machine bootup. piG ib a block diagram showing a previously known 

While the Preston system is more secure in one sense— ^y^tcm in which multiple users share possession of one or 

because one needs the bootup-generated DAC seed to 45 ^^^^^ ^^^^ fo, either symmetric or asymmetric 

decrypt the Preston extended-label before being able to use encryption and decryption; 

the mandatory key to further unlodc the Pond label-thc rg. 2 is a block diagram showing how privately- 
same feature is also a drawback. A file generated under the ^ .^le files might be stored in a common memory or 
Preston system cannot be used m an off-enterpnse machme , ™™r„,.«,v,*;««e ^k,««-i. 

... .jr^*y^ J passed tlirougn a common communications channel; 

that does not have access to the bootup-generated DAC seed. 50 

Thus files are not easily exchanged between different ^ f^ows a file labelhng system m accordance with 

machines of an authorized user. This can be an inconve- invention, 

nience in an age where users likely to want to seamlessly ^ shows one data structure for an Access Control 

move from one machine to another and still access the same Table (ACT) having individual User's Access-Control- 

files 55 Entries Records in accordance with the invention; 

TVT,^v™«*T 5a shows a second data structure for a file in 
SUMMARY OF THE INVENTION accordance with the invention; 
An improved, machine-implemented file labelling pIG. SB shows a data strucmre for an Access Control- 
method and apparatus are provided in accordance with the Entries Record (ACER). 

invention for securing both file data and file label contents 60 FIG. 6 is a flow chart of a file access procedure in 

on a per-user basis. accordance with the invention; and 

Generally speaking, each authorized user employs his or 7 is a block diagram of a computer system in 
her own 'private' user key (e.g., a private decryption key or accordance with the invention, 
a private password) to gain intelligent access to privately- 
encrypted portions of a file label. If the 'private' user key of 65 DETAE^D DESCRIPTION 
one user is compromised, the usability of that one key can FIGS. LA and IB provide a basic introduction to the 
be programmably cancelled out from the file label without topics of file encryption/decryption and management of 
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encryption/decryplion keys. FIGS. lAand IB also introduce The most common use for a public-key/private -key sys- 

drawing symbols that are used in FIG. 3. Those skilled in the tem 100 is where a first user wishes to send a message in 

art may choose to quickly glance at FIGS. lA and IB and confidence, over a publicly-accessible communications 

then skip forward to the discussion of RG. 2. Referring to channel (e.g., 102) to a second user. The first user obtains the 
FIG. lA, a first system 100 is shown that relics on the 5 public E_Jcey 115 of the second user and encrypts the 

public-key/private-kcy paradigm. The RSA public-key/ original message 101. On receipt, the second user applies his 

private -key system is an example. or her private D Jccy 125 to decrypt the received *FILE 

First file data 101 is provided in plaintext form (e.g., DATA* 102 and thereby intelligibly access the information 

*abcdef*) for storage in a nonvolatile, computer- read able contained therein. 

media (e.g., on a magnetic floppy diskette) or for transmis- 10 An advantage of the public-key/privatc-key system 100 is 

sion through a non-secured transmission channel (e.g., over that users can freely hand out their public key without 

the Internet or another non-secured network). worrying about who has possession of this public key 115. 

A first encrypting unit (E_unit) 110 receives digital Users are each responsible for maintaining the confidcnti- 

signals representing the plaintext version (e.g., 'abcdcf') of ality of their own private key 125. Thus, third parties (such 

the first file data 101 at one input. A 'public' encryption key as a system administrator) do not need to become involved 

(EJCey) 115 is applied to a second input of E__unit 110. in the controlled distribution of encryption and decryption 

The first encrypting unit 110 uses the pubUc_E„Key 115 to keys. (As an aside, although FIG. lA shows a system where 

encrypt first FILE DATA 101 and to thereby produce there is a 'public' E_Jcey and a 'private' D_key, it is to be 

encrypted second *FILE DATA* 102 (e.g., *!#$%"&'). The understood that a 'private' E_key may be used for encryp- 

encrypted second *FILE DATA* 102 is essentially unintel- tion and that a companion 'public' D_Jcey may be used for 

ligible (e.g., '!#$%"&*) and its deciphering generally calls decryption. In this latter case, the user's public D_kcy is 

for access to a soonndescribed 'private* decryption key used to authenticate that user was the transmitter of the 

(D^key). information originally encrypted with that user's private 

For sake of convenience, data that has been once- E_key. In some systems, a same public key functions as 

encrypted is denoted herein as bounded between a pair of both the pubUc E_key and the public D_key while a 

asterisks. An example U, *HLE DATA* 102 as shown in different private key functions as both the private D„key 

FIG. lA. private E_Jcey,). 

Intelligently useful data that has been obtained by A second kind of encryption/decryption system 100' is 

decrypting pre-encrypted data is denoted as adjacent to, but shown in FIG. IB. Like reference numerals are used in FIG. 
outside, a pair of asterisks. An example is, FILE DATA** ^ IB for elements corre^nding to those of FIG. lA. As such, 

103 as shown in FIG. lA a detailed description is not provided. 

The encrypted *FILE DATA* 102 may be recorded as One difference between the second system 100' (FIG. IB) 

such in a computer- readable media and/or transmitted over and the first system 100 (FIG. lA) is that the encryption and 

a publicly-acccssiT)le transmission channel. decryption keys, 115* and 125', of the second system 100* are 

When intelligible use of the *FILE DATA* 102 is desired, each multi-user shared keys. This means that multiple users 

signals representing the *FILE DATA* 102 are delivered to have possession of the encryption key 115' and multiple 

a first input of a first decrypting unit (D_unit) 120. A users have possession of the decryption key 125*. No key is 

"private" decryption key (D_key) 125 is supplied to a privately held by one user (and his/her trusted agents, if 

second input of the first decrypting unit 120. The combina- any). 

tion of an asymmetric decryption algorithm (e.g., RSA) In so-called "symmetrical" encryption/decryption 

carried out by the D_unit 120 and the private D Jcey 125 systems, the multi-user shared E_key 115' is the same as the 

operates on the encrypted *FILE DATA* 102 to produce multi-iiser shared D__key 125^. Examples of symmetrical 

decrypted FILE DATA** 103. This FILE DATA** 103 is encryption/decryption systems include, but are not limited 
usable in the same way as the original FILE DATA 101. The 45 to: (1) XORring with a randomly-generated key stream, (2) 

act of decrypting the encrypted *FILE DATA* 102 is X_NORring with a randomly-generated key stream, (3) 

occasionally referred to herein as 'uncovering' or 'unlock- DES (the U.S. Government -sponsored Data Encryption 

ing' such *FILE DATA* 102. Standard), (4) Triple-DES (5) RSA RC4™, and (6) 

Decryption key 125 is referred to as a user's "private" Blowfish, the latter being attributed to Bruce Schncier. 
decryption key because only one user and his or her trusted 50 The problem with the second system 100' (RG. IB) is, as 

agents are intended to be given possession of this D_key already explained above, that the risk of compromise of a 

125. shared encryption key 115' and/or a shared decryption key 

The user's "public** encryption key (E_key) 115 may be 125' increases as more users are given possession of that key. 

handed out to any member of the public. The user's private A system administrator often has to become involved in the 
D_Jccy 125 cannot be easily derived fi^om the user's public 55 secured distribution of the shared E__ and D_keys to the 

E_Jcey 115. Thus, after a general member of the pub He various users who are to be authorized to respectively 

employs a user's public E__Hey 115 to create the encrypted perform er^ryption and/or decryption with those keys. 

*FILE DAL\* 102, only that user (and his or her trusted There is however one advantage that the second system 

agents) can easily decrypt (unlock) the resultant *FILE 100' of FIG. IB has over the public/private key-pairing 
DATA* 102 to produce the plaintext replica, FILE DATA** 60 system 100 of FIG. lA. The advantage is that the same 

103. encrypted *FILE DATA* 102' does not have to be stored 

First system 100 is referred to as an asymmetric and/or retransmitted a plurality of times, with each such 

encryption/decryption system because the same key is not storage or transmission process being dedicated to a unique 

usable for both encryption and decryption. An example of user. Shared *FILE DATA* 102' can be woriced on (or 
such a pubUc key/private key asymmetric system is the RSA 65 worked off of) by a group of access-sharing users. This 

public^rivate algorithm available bom RSA Data Secmty, facilitates so-called groupware projects wherein multiple 

Inc. users contribute to the contents of a single file. Where 
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appropriate, the shared *FILE DATA* 102* can be simulta- LABEL portion 302^ over a digital data communications 

neously broadcast to a group of access-sharing users over a network or a Like data transmission means, 

network or by other broadcast means (e.g., from a space As seen in FIG. 3, signals 311 representing the plaintext 

satellite). version, FILE_N DATA 301 are encrypted by a first 

FIG. 2 shows a possible alternative 200 to the key-sharing 5 encrypting unit (E_unit) 310. First E_uml 310 can carry out 

system 100* of FIG. IB. In the multi-user public-key^rivate- a selectable one of a plurality of encryption processes such 

key system 200 of RG. 2, box 250 represents a computer- as, but not limited to: (1) XoRring the original signals 311 

readable storage media (e.g., a magnetic or optical disk) with a randomly -generated key stream, (2) X_NORring 

which is accessible to multiple users. with a randomly-generated key stream, (3) performing 

As seen in FIG. 2, the plaintext version of FILE_1 DATA according to the U.S. Government-sponsored Data Encryp- 

201 is encrypted (locked) according to the encryption algo- tion Standard (DES), (4) performing Triple-DES. (5) pcr- 

rithm of encrypting unit 210 and further according to a forming RSA RC4™, (6) performing RSA RCS'^m, and (6) 

supplied User_#l PubHc_E_Jcey 215 to thereby securely carrying out the Blowfish algorithm. The selected encryp- 

storc the encrypted version *FTLE_1 DATA* 202 in the tion algorithm is defined by a System-supplied Encryption 

commonly-accessible data-conveying media 250. Algorithm Select signal (SysEAS) 317. 

A companion decrypting tmit 220 and a companion The SysEAS-sclectcd encryption-algorithm of first 

User_#l Private_D_Jcey 225 are needed for easily obtain- E_unit 310 uses a System-supplied Encryption key 

ing the decrypted version, FILE_DArA** 203 from the (System_E_key) 315 for generating the encrypted 

commonly-accessible data-conveying media 250. *FILE_N DATA* portion 302a. The latter portion 302fl is 

Similarly, the plaintext version of FILE_2 DATA 204 is ^° thereafter transmitted to the commonly-accessible data- 
encrypted with the algorithm of encryption unit 211 and with conveying means 350. 

a supplied User_#2 Public_E_Jcey 216 to thereby form the The System_E_key 315 is preferably generated initially 

encrypted information of *FILE_2 DATA* 205. *HLE_2 by a system-contained random number generator 305 and 

DATA* 205 is then stored into the commonly-accessible thereafter stored in an administrator-controlled secure stor- 

data-ccmveying media 250. The decryption algorithm of ^ge means 306 (e.g., a nonvolatile storage area whose 

companion decryption unit 221 and the corresponding contents are encrypted with an administrator's publk: E_j£:ey 

User_#2 Private-D_key 226 is required for easily recon- and afterwards decryptable only with the administrator's 

stituting the plaintext, nLE_2 DATA*' 206 &om the closely-guarded private D_Jcey. 

commonly-accessible data-conveying media 250. If desired, the SysEAS signal 317 may also be initially 

The advantage of system 200 is that the decryption keys. generated by the same or another random number generator 

225 and 226, are kept privately by their respective users 305 and the generation of the System_£_key 315 may be 

(User_#l and User_#2). The likeUhood of compromise is taUored accordingly. After its initial generation, the SysEAS 

lessened as compared to the key-faring system 100' of FIG. ^ig^^l ^17 may also be stored in the administrator-controlled 
IB. If the User_#l Private-D_Jcey 225 is compromised, 35 secure storage means 306 if desired, 

then only *FILE_1 DATA* 202 is put at risk. ♦FILE.^ At the time that the random number generator 305 pro- 

DATA* 205 remains secure. The drawback of system 200 duces the System_E_key 315. a companion decryption key 

(HG. 2) is, as explained above, that it makes it difficult for (System_D_key) 316 is also produced, 

multiple users to share intelligible access to a common data At the time that the SysEAS signal 317 is produced, a 
file. 40 companion System-supplied Decryption Algorithm Select 

FIG. 3 shows a system 300 in accordance with the signal (SysDAS) 318 is also produced. Select signal. Sys- 

invention. System 300 provides the advantages of a public/ DAS 318, specifies the decryption algorithm that is to be 

private key-pairing system (hereafter, also referred to as a for decrypting the ♦FILE__N DATA* portion 302a. 

*P/P-pairing system') and at the same time allows multiple After its initial generation, the System_D_key 316 is 
users to securely share intelligible access to a common data 45 preferably stored in the secure storage means 306. After its 

file, 302. initial generation, the SysDAS signal 318 may also be stored 

In system 300, a file label 302^7 is prefixed to, or otherwise in the secure storage means 306. In cases where the 

attached to, or otherwise associated with a correspondingly- System_D_key 316 is the same as the System_E_key 315 

encrypted file data portion 302fl. The combination of file (in symmetrical encryption/decryption systems), key 316 
data portion 302fl and file label 302& is referred to here as 50 obviously does not have to be stored in secure storage means 

a by-the-user secured *FILE_N* 302. Dashed line 351 306 after key 315 is stored in the same secure storage means 

represents the logical attachment or other logical association 306. In cases where the SysDAS signal 318 is the same as 

of the *FILE_N DATA* portion 302a with the FILE_N the SysEAS signal 317. the second signal 318 does not have 

LABEL portion 302f). As a general rule, both the *FILE_N to be stored in seciue storage means 306 after the first signal 
DATA* portbn 302a and the FILE_N LABEL portion 3026 55 ^17 is stored in the same secure storage means 306. 

arc carried (e.g., stored) in a commonly-accessible data- In one species of the invention, the selectable system 

conveying means 350. If the *FILE_3r DATA* portion encryption algorithms provided by first E__unit 310 are 

302a is moved elsewhere, the FIT .F_M LABEL portion symmetrical (reversible) ones such as exclusive -ORring or 

302/? travels with it. The conunonly-accessible data- exclusive -NORring of the plaintext message with an 
conveying means 350 can include a magnetic disk or an 60 encrypting keystream. In such a case, the System_3_key 

optical disk, or a magneto-optical disk, or a data storage 315 is the same as the System__D„key 316. (And although 

tape, or another such form of data storing and/or conveying not shown, in such a case line 315 may connect directly to 

means, that makes its carried data signals accessible to a line 316 in FIG. 3.) The SysDAS signal 318 may, but does 

plurality of users by a variety of pathways. The commonly- not have to, be equal to the SysEAS signal 317. 
accessible data-cooveying means 350 can alternatively or 65 In another species of the invention, at least one of the 

additionally include a transmission means for transmitting encryption algorithms carried out by first E_unit 310 is part 

the *FILE__N DATA* portion 302a and the FILE_N of a non-symmetrical (noo -reversible) encryption/ 
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decryption pair such as RSA public/private key-pairing. In 
such a case, the System„D_key 316 is not the same as the 
System_E_key 315 and appropriate measures are taken to 
relay the companion System_D_key 316 through a soon- 
described E„unit 330 for later retrieval by authorized users. 
The SysDAS signal 318 may, but does not have to, be equal 
to the SysEAS signal 317 in this asymmetrical case. 

The supplied System_D_key signal 316 is placed on a 
plaintext-receiving, first input 331 of a second encrypting 
unit (E_unit) 330 for encryption thereby. In one 
embodiment, the SysDAS signal 318 is routed as indicated 
by 318a to be combined with the System_D_key 316 and 
also placed on first input 331. In another embodiment, the 
SysDAS signal 318 is routed as indicated by 318f> and 
supplied in plaintext form to the FILE__N LABEL portion 
302^. If system performance speed is a priority over 
security, the 3186 path is preferred. 

The second E_unit 330 is preferably part of a public/ 
private key-pairing system (P/P-pairing system), 330/340. 
For each User_#X (where X=l, 2, 3, ... , etc.), the pubhc 
encryption key of that User„#X is placed on a key-receiving 
input (>) 335 of second E_unit 330 and that key is used for 
encrypting the signals, 316 and optionally 318a, 393a, that 
are present on the plaintext-receiving, first input 331 of 
second E_unit 330. The resulting, encrypted signal 332 is 
recorded into a User_#X-accessible, Access-Control- 
Entries Record (*ACER*) within nLE_N LABEL portion 
3026. FIG. 4 shows one possible data structure for an 
*ACER* which will be discussed shortly. 

The User__#X public E_Jcey that is applied to the key- 
input 335 of second E_umt 330 is obtained from a public/ 
private key-pair distributing unit 390 (hereafter also, 'P/P 
key-pair distributor 390'). P/P key-pair distributor 390 is a 
machine-implemented entity that supplies a Unique User 
Identification signal (UUID) 393 for each User_#X at the 
same time that it suj^lies the public E_key 395 of that user 
number X. 

In one embodiment, the UUID 393 that is produced by 
unit 390 moves along path 3936 for storage in plaintext form 
within the ACER of User_#X. In another embodiment, the 
UUID signal 393 moves along path 393a for encryption by 
second E_unit 330. Path 3936 is preferred for performance 
speed reasons and is therefore shown as a solid line in FIG. 
3. 

In one asymmetric embodiment, where the Systcm_E„ 
key 315 is not the same as the System_D Jcey 316, a 
plaintext copy of the System E_key 315 is obtained firom 
the secure storage means 306 and applied to the first input 
331 of second E_unit 330 for inclusion as ciphertext within 
the *ACER* of appropriately authorized users. If the 
SysEAS signal 317 is not the same as the SysDAS signal 
318, that too may be applied to the first input 331 of second 
E_unit 330 for inclusion as ciphertext or plaintext within 
the *ACER* of appropriately authorized users (e.g., those 
users who arc authorized to modify the contents of 
*FILE_N DATA* portion 302a). 

When a specific User__#X wishes to intelligibly read the 
encrypted *FILE_J^J DATA* portion 302a, that User_#X is 
asked to first perform an identity-authenticating task (e.g., 
supply his or her password). The identity-authenticating task 
causes his or her private decryption key (D_key) to be 
supplied a key-input 345 of decrypting unit 340. D_unit 340 
is the decryption companion of second E_unil 330. The 
ciphertext-receiving input 341 of D_unit 340 receives the 
*ACER* entries that had been encrypted with that user's 
Public _E _key 395 and stored in nLE_N LABEL portion 
3026. 
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When the proper private decryption key 394 of User_#X 
is suppUed to key-input 345, decrypting unit 340 produces 
at its output 342, a usable Systcm_D^ey** 326 which is 
a replica of the original System_D_key 316. The produced 
5 System_J)_key** 326 is then applied to key-input 325 of 
decrypting unit (D_unit) 320. D__unit 320 is the decryption 
companion of E_unit 310. 

In the one embodiment where the SysDAS signal 318 
takes path 3186, the label-stored copy of that signal is 
extracted as SysDAS signal 3286 and applied to the decryp- 
tion algorithm select terminal 327 of D_unit 320. 

Id the other embodiment where the SysDAS signal 318 
takes path 318a, the label-stored ciphertext copy of that 
signal is passed through D__unit 340 and extracted as 
SysDAS* * signal 328a firom output 342 of D_unit 340. The 
extracted SysDAS** signal 328a is then applied to the 
decryption algorithm select terminal 327 of D__unit 320, 
The notation *SysDAS(**)'is used in FIG. 3 to indicate that 
this signal can be either the SysDAS** signal 328a or the 
SysDAS signal 3286 depending on what path, 318a or 3186, 
20 was taken in the creation side of the FILE_N LABEL 
portion 3026. 

The privately decrypted System_J)_key** signal 326 
and the extracted SysDAS(**) signal 3286 (/328a) are 
respectively supphed to the key-input and decryption algo- 
^ rithm select input ports, 325 and 327, of decrypting unit 320. 
The ciphertext-input port 321 of D_unit 320 receives the 
*FILE_N DATA* portion 302a from the commonly- 
accessible data-conveying means 350 and decrypts the 
received signal to thereby produce the plaintext replica, 
^ plaintext version, HLE^N DATA** 303. 

Once obtained, the decrypted FILE_N DATA** signals 
303 may be stored in computer-readable memory (e.g., 
volatQe RAM) or otherwise privately used by the authorized 
^5 Uscr__#X as desired. Such use is generally indicated by path 
304, 

If Uscr_#X is authorized to modify the data within the 
*FILE_>I DATA* portion 302a of commonly-accessible 
data file 302, then User_JfX is given access to the Systenx- 

4Q E__key 315. After modification, the data of pre-decrypted 
portion 303 is conveyed by path 308 and becomes the data 
of portion 301. The modification-authorized user may then 
obtain the System E_key 315 and the SysEAS signal 317 
firom the secure storage means 306. 

45 In the embodiment that employs a symmetrical 
encryption/decryption system 310/320, it is possible to 
avoid the step of obtaining the System_E_Jkey 315 firom the 
secure storage means 306. The SysDAS(**) signal 3286 
(/328a) is a replica of the System E_key 315 and thus 

50 Uscr_#X is inherendy given possession of the System_E„ 
key 315 by his/her prior, private decrypting of his/her 
corresponding *ACER* (User's Aocess-Control-Entries 
Record). 

If a non-symmetrical encryption/decryption system is 
55 defined by first E_unit 310 and D_unit 320, the System_ 
E_key 315 would have to be distributed to the authorized 
User_#X by a secured channel. The User's Access-Control- 
Entries Record (* ACER*) can function as one such channel 
for distributing the System_E_key 315 to authorized users. 
60 Alternatively, the authorized User_#X may have go to the 
secure storage means 306 and fetch a plaintext version of the 
Syslem_E.j£ey 315 from there. The embodiment wherein 
modification-authorized user obtains a decrypted rqjlica 
SystemJEJcey** of key 315 from his/her *ACER* is 
65 described below with reference to FIG. 4. 

As indicated above, the conveyance of a user's private 
D_key 394 to key-input 345 generally calls for the perfor- 
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manoe of an idenlity-authenlicaling task by that user. In one actual use, the entries of each User's Access-Control-Entries 

embodiment, User_#X is asked (e.g., by an on-screen Record may be positioned variably as appropriate. Column 

dialog box) to enter or otherwise input his^e^ password 406 docs not have to be part of the ACT 400 but is iUustrated 

(e.g., through the terminal keyboard). The submitted pass- for ease of cross referencing to specific records, a, b, 

word signal is applied to password-input port 361 of 5 c, . . . , n. 

identity-authenticating unit 360. If a proper password signal Pairs of asterisks are used to indicate the presence of 

for that logged-in user is submitted, the identity- ciphertext as before. Data that is encrypted is denoted herein 

authenticating unit 360 sends release signals to the P/P as bounded between a pair of asterisks. Each *Sys_D_key* 

key-pair distributor 390 for causing distributor 390 to supply ^^^^ (column 402) of each User_#X's ACER, for example, 

that user's private D^ey 394 to key-input 345 and for lO encrypted with that user's pubUc E key, such that only 

further causing distributor 390 to supply that user's UUID ^5 (^^^^ hWher trusted agents if any, who are given 

signal 393 to a UUID-input port 364 of a label-searching possession of h^s^e^ private D key) can ^ 

engine 365. The password-based release of the user's private ^J^^-^T^T ? ^^'f ? corresponding 

D_key 394 and of the user's UUID signal 393 is depicted by decrypting the mchided *Sys_J) Jcey* entry 

by release switches 344 and 346 respectively in FIG. 3. is ^ R^plicas of the ongmal System J_key 316 are thus 

, . ^ . . TiTrTT^ * 1 ^n-i • . securely distnbuted to each authorized user (and his/her 

In one embodiment, each user s UUID signal 393 is at . r i_ • r i.- 

1 . aX "'^^'"^'^"'^ / Vi , trusted agents, if any, who are given possession of his/her 

least 40 bits long and more preferably 128 bits long or • * rf i j- -i\ 

1 I* u u- vcj-j pnvate D_key or corresponding password), 

longer. It can be shorter if desired. *^ _ . . . / . ft . . , - 

... ^ - , ^ i_ , - . It IS to be understood that although the plamtext string 

In one embodiment, the sum length of each user s pnvate .1234567' is seen in FIG. 4 bounded between asterisks for 

p_key 394 ^md of that user's public E_key (the key-pair 20 ^^^^ ^^^^ *Sys„D_key' cohimn 402, this is done 

length) ^ preferably m the range of approximately 360 bits appreciation of the invention. In acUial practice, 

to 204S bits and more preferably it is equal to approxmiately *Sys_D_Jcey* entry 402a^ of each respective ACER_ 

7&8 bits or more. through ACER_#n should be a different, nonsensical, 40 

The System_D_key 316 is preferably at least 40 bits bit or longer string of I's and O's. Each such string is 

long and more preferably 128 bits long or longer. It can be decrypted into the plaintext System_D_Jcey** 326 (e.g., 

shorter if desired. '1234567' ) with the private D_Jcey of the associated user. 

Each user's pair of private D_and public E_Jceys, 394/ By way of a more detailed illustration, consider the enuies 

395 is preferably defined by a pseudo-random number of the fourth Access-Control-Entries Record which is 

generator so that this key-pair is essentiaUy random with the 3^ denoted as ACER_JW. The user associated with this 

exception that this key-pair is not equal to or otherwise ACER_#d is named "Bob". A first access control entry 

substantially too close to another user's private/private key- (acE) 401d associates the present ACER_#d with the user 

pair and that the key values are relatively prime numbers. named Bob by way of a unique user identification string 

Each user's UUID signal 393 is preferably defined by a (e.g., Bob's UUID) or by way of other appropriate means, 

pseudo-random number generator so that this UUID is 35 Each User_ID entry 401a-vi may be encrypted or not. This 

essentially random with the exception that this UUID is not option is denoted by the optional-encryption indicators 

equal to or otherwise substantially too close to another (*)... (*) formed about the column header, (*)User_ID(*). 

user's UUID and is thus unique. Each user's UUID signal The encrypted version, *User__ID* is used if path 393^ is 

393 is generally a nonsensical, relatively-long bit stream that folbwed in FIG. 3, The plaintext version, User__ID is used 

is hard to guess or remember. In one embodiment, a plaintext ^ if path 3936 is followed in FIG. 3. Use of the plaintext 

copy of the user's name is combined at the time of UUID version of User_ID is preferred if ^eed is of primary 

creation with the current date and the current time (down to concern because the D_unit 340 takes time to decrypt each 

at least the latest second) and hashed to generate the pseudo- privately encrypted portion of data. In this particular 

random UUID. example, Bob's User_ID is his UUID string. This UUID 

Upon rece^Jt of a released user^s UUID signal 393, the 45 string is not encrypted with Bob's private key and appears 

label-searching engine 365 scans the *ACER*'s within as plaintext. Although the entry 401rf shows as "Bob 's_ID" 

FILE_N LABEL portion 3026 for an *ACER* having a in FIG. 4, it is to be understood that in actual use the UUID 

matching UUID string. The scanning connection is gener- entry 401 J will often be a nonsensical, 40 bit or longer string 

aUy indicated by line 366 of FIG. 3. If users' UUID's follow of I's and O's. 

path 393fl during the formation of each *ACER*, then the 59 By way of contrast and for completeness. Bill's User_ID 

label -searching engine 365 scans for matching UUID's by 401e is encrypted by Bill's private E_key and is shown to 

obtaining plaintext from the output 342 of D_imit 340. This have the form, * Bill's*. As indicated above, this approach is 

latter approach is less preferred, as explained above, because less preferred if Bill's User_ID is his UUID string because 

it slows down file access speed. The preferred implementa- the latter is essentially nonsensical in the first place and 

tion is to store UUID's as plaintext in the *ACER* *s. 55 because resort to unnecessary encryption and decryption 

When a matching UUID is found, label-searching engine consumes time as well as system resources. If Bill's User_ 

365 (or another responsive means) causes the corresponding ID were his name in ASQI format rather than his UUID 

*S^_D_key* signal fi-om the ACER of the matching string, and it was desirable to keep the identities of autho- 

UUID to pass through D_unit 340 and the resultant rized users of a given RLE_N LABEL portion 3026 

System_D_key** 326 signal to be supplied to input 325 of eo confidential, then in such a case it may be desirable to 

D_unit 320. encrypt each User_ID with that user's public E_Jcey. In the 

FIG. 4 illustrates one data structure that may be used latter case, the *User_ID* entry would be decrypted by 
within the FILE_N LABEL portion 3026 of FIG. 3. The D_unit 340 before being submitted to input 366 of label- 
illustrated Access Control Table (ACI^ 400 is shown with searching engine 365 for comparison with the released 
aligned columns 401-405 for the entries of each User's 65 UUID signal 393 at UUID-input port 364, 
Access-Control-Entries Record (ACER) so that the func- Although FIG. 4 shows column 401 denoted as 'User_ 
tionality of each type of entry can be easily appreciated. In ID', it is within the contemplation of the invention to more 



07/02/2003, EAST Version: 1.03.0002 



5,953,419 

13 14 

broadly define this column 401 as 'ACER_ID' and to have to be displayed (or hidden) when queried by various users. 

randomly-generated passwords stored in one or more entries (See also the below discussion of field 555.) 

of column 401. These ACER_ID passwords can be given to Qne further example of special processing on a per-ACER 

'generic- usem for locating respective ACERs that each ^asis (405c) is the granting of different access rights to 

contains an ;Sys_D_Jcey signal covered by a correspond- 5 ^1005 of a given data file 302 (RG. 3). Some 

mg encryption algorithm. TTie key ±al un«yers the '^^^^^ individuals may be authorized (e.g., by a system 

D_Jccy* Signal of each such gencnc ACER IS referred to as j*-*»\/u a ^ ^ / ♦mr c kt 

that ACER^private key rather than as the private key of a if ^S!?f "'"'^ i° ""^^^ h T . ^^-m 

particular user This aspect is further discus^d for field 552 P''"'.^" ""^^I'T"/* ^'^''Z 

of FIG 5B LABEL portioa M)2b. Some individuals may be authorized 

T:ir- a « tu:^ Ani» - «f to have read and write access to *FILE N DATA* portioa 

Still referrmg to FIG. 4, a thutl entry 403a-n of each ^nrt u . j i * i-nc ktt 7"ncT %<v>l 

ACER preferably contains an indicator of the System 302a but read-only access to RLE LABEL portion 3^ 

Decryption Algorithm Selection signal (318). The header of Yet other mdividuals may be authonzcd to have read and 

column 403 is indicated as (*)SysDAS(*). Again, encryption ^ritc access to both the *nLE_J^ DATA* portion 302^ and 

with the user's public E_key is optional and less preferred. FILE_N LABEL portion 302!? of a given FILE_N 302. 

-nius most of the iUustrated entries of column 403 show the Inclusion of such access-rights code is shown at entry 

plaintext *RC4.05* (to indicate as a fictitious example, number 405£f. 

version *0.05' of the RSARC4™ algorithm). Although the Some users may need to know that they belong to a 
plaintext name of the decryption algorithm is seen in FIG. 4, particular "group" of users as i^ccially defined with respect 
in actual use that entry would generally be a coded value to this given FILE_J^ 302. Inclusion of such a group- 
selected from a group such as 0 through 6, with each value association code is shown at entry numbers A05b and 405/. 
representing a specific, predefined decryption algorithm. David and Frank are associated through their respective 
There is no significant, added benefit to encrypting that ACER'S to a Group#l in so far as the given FILE_N 302 is 
value with the user's public encryption key (395). However, concerned. One reason may be that they need to collaborate 
if added security were desired along this line, the entries of on work on a particular section of the given FILE_N. More 
column 403 could be each so encrypted so that only those generically, entry 4056 may be viewed as a group identify- 
who possess the user's private decryption key (345) are able ing code for specifying a group of ACER'S or a group of 
to easily obtain the plaintext version of the stored *Sys- users to which the respective ACER or respectively- 
DAS* signal from that user's ACER. In the latter case, paths associated user belongs. 

318a and 328a would be followed in FIG. 3. Entry 403e of ^ By way of further example of the kinds of additional data 

FIG. 4 (row e, column 403) indicates this optional configu- that might be passed through a given user's ACER, suppose 

ration. that within the so-called, plaintext version of the FTLE_N 

Referring to columns 404 and 405, each Access-Control- DATA 301 there was nonetheless a small, 'buried' dphertext 
Entries Record may have additional entries that are either portion 301a that is covered by an E_j£cy distinct from the 
encrypted (404) or not (405) with that user's public E_Jccy keys applied to 315 and 335. Suppose this 'buried' cipher- 
er with some other encryption key. text portion 301a is to be intelligibly accessed by only a 

By way of example, suppose the encryption/decryption subset of the authorized users who are authorized to access 

system 310y320 is asymmetric and the user named, Shawn the remainder of *FILE_N DATA* portion 302a. The 

is to be permitted to modify the *FILE_N DATA* portion D^ey for decrypting this *buried* ciphertext portion 301a 
302a by following the route 308 described above. In such a ^ can be distributed to the subset of the authorized users 

case, Shawn has to be given some way of applying the through their respective ACER'S in the same way that the 

System_E_Jcey to input 315 of first E_.unit 310 and of System_J>_key 316 is distributed to all the authorized 

applying the SysEAS signal to input 317 of that E_unit 310. users. For each member of the subset of the authorized users. 

One way of securely distributing the asymmetric System the D_key for the 'buried' ciphertext portion 301a is 
E_key 315 that was used for *nLE_N DATA* portion 45 covered (encrypted) by the respective public E_j£ey of that 
302a to Shawn (and to his trusted agents, if any, who are member and the resuh is stored as *Othcr_J)is'd_JCey* 
given possession of his private D_key and/or passwords) is (Other Distributed Key) in that member's ACER. Inclusion 
by placing an encrypted version (*Sys_E_JCey*) of that of such a privately-covered 'Other Distributed Key* is 
System_E_key 315 in the nLE_N LABEL portion 3026. shown at entry number 404d by way of example. 
This encrypted version (*Sys_E_Key*) is covered by 50 Each user's ACER record may have its own uniquely 
Shawn's public E__key and placed in Shawn's ACER as formatted extension portion. The extension portion may be 
indicated at entry 404a. The Sys JAS code (the System- provided for holding special entries that arc not regularly 
supplied Encryption Algorithm Select signal) can be passed found in most of the system's ACER's. The use of special 
to Shawn through his ACER either as the illustrated, non- extensions works to conserve storage space by not unduly 
secured entry 405a; or if more security is desired, as another 55 extending the size of most ACER's for entries that are not 
public E_key covered item of the form *Sys_EAS* (not generally used. The format specification for a specially- 
shown in FIG. 4). extended ACER may be provided in a Record Jormat entry 

By way of further example of the kinds of additional data such as shown at 405e. If extra security is desired, an 

that might be passed through a given ACER, suppose that encrypted version, *Record_Format* (not shown) may be 
the ACER'S of certain individuals (Mick for example) are to 60 instead stored in the *Other_Sccured* area 404. 

be processed in a special way by an appUcatioo program that FIG. 5A shows one example in accordance with the 

refers to that ACER. A special-processing request code invention of a data structure 500 for a FILE LABEL portion 

(Special Pro Code) may be included in either plaintext fonu 5026 and for a postfixed *FILE DAIA* portion 502fl of a 

or ciphertext form in a respective one of areas 405 and 406. stored file 502 in accordance with the invention. When 
Such an example is shown generically at entry number 405c. 65 physically implemented, data structure 500 may be recorded 

One example of special processing on a per-ACER basis on a machine-readable medium such as magnetic disk (not 

(405c) is defining how the contents of the given ACER are shown) and appropriately encoded for functional use by a 
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prespecified, data-processing meaos (e.g., a targeted, digital each time minor revisions are made to the format of the &le 

computer that has been programmed to cooperate with the label 5026. The label-using software (600 of FIGS. 6A-6B) 

various portions of data structure 500 as indicated). The should consult the major and minor version number fields 

machine-readable medium (e.g., disk) is ope rati vely coupled 516a, 5166 to determine what format is being used and it 

to the prespecified, data-processing means for cooperating 5 should then comply with that format, 

therewith in accordance with the indicated fiinaions of the System Decryption Algorithm Select code (SysDAS) 

data structure 500. This field 517 contains the system decryption algorithm 

Data structure 500 may additionally or separately be selecting code (SysDAS) which is defined as signal 318 in 

physically transmitted thn^ugh a transmission medium (e.g., ^ ^^^^h is distributed to authorized users in 

over a digital communications network) for receipt and 10 pl^^i^.text foi^ by way of path 3186 in F^^^^ 

intelligible use by a targeted data-processing means. ""^^J^l^^^^l^J^ l^^7^u i^i^^ ^^A^^^'^r^.u ^ 

^ « 1^ J ui 1 . J «i cft^ u path 3286 in HG. 3 and then apphed to mput 327 of the 

The fields and/or blocks within stored file 502 are shown p 

in FIGS. 5A-5B and are described as follows. Jf ^^^^ ^ jhe same as signal 317 (FIG. 3), then this 

Length of this Label (Relative End Pointer) g^ld 517 may also be viewed as containing the System 

This first field 511 in the data structure 500 of FIG. 5A 15 Encryption Algorithm Select code (SysEAS). In one 

contains a signal representing the total length of the present embodiment, a coding system such as the following is used: 

label portion 5026 in terms of kilobytes, or of bytes or of 0=No decryption needed, l=Blowfish, 2=DES, 3=Triple 

bits, or of another appropriate measure. Field 511 can also be DBS, etc. 

viewed as a relative address pointer to the end point 589 of In alternate embodiment, this SysDAS field 517 is elimi- 

the present label portion 5026. In one embodiment, field 511 20 nated firom the common portion 511-540 of the FILE 

defines label length in terms of kilobytes. The minimum LABEL 5026 and is replaced with a privately-encrypted 

increment of the label length in this embodiment is 1024 * SysDAS* entry (not shown) in each user's respective 

bytes. Each 1 kilobyte increment of label length accommo- ACER, 571, 572, etc. This alternate approach corresponds to 

dales an additional 3-4 new ACER'S (approximately). paths 318fl and 328a of FIG. 3. 

Length of Digital Signature 25 Length of System_D_key 

Second field 512 contains a signal representing the total The length of the system decryption key (Sys__D_Jcey 

length of a 'digital signature' that is stored in below- 316) can vary from one situation to another for numerous 

described field 540. The length (in terms of bytes or bits) of reasons. Performance ^ed requirements may take priority 

the digital signature 540 can vary with some algorithms. The over security needs or vice versa. Government restrictions 

data in field 512 indicates where the last valid bit of the 30 may limit the size of the Sys_D_key 316 to no more than 

digital signature is located. a certain length (e.g., no more than 40 bits). Field 518 serves 

If a first *aaive' ACER 571 immediately follows the as a sanity-dieck for the label-using software. If D_unit 340 

digital signature 540, then field 512 may also be viewed as produces at its output 342, a system D_key* * signal 326 

a relative pointer to the start of the first active ACER 571. having a length greater than that specified by field 518, a 

Plaintext Banner 35 variety of actions may be taken. In one embodiment, the 

It is common practice to include a plaintext banner section excess bits of signal 326 are stripped off before application 

such as 514 in a file label. The plaintext banner section 514 to input 325 of D_unit 320. In another embodiment, the file 

may be filled with any desirable data by the last modifier of access attempt is refused. In third embodiment, a warning is 

the label portion 5026. Typically, the plaintext banner sec- issued and the excess bits of signal 326 are stripped off 

tion 514 is used for distributing an ASCII-encoded message 40 before application to input 325. 

to other users such as, "This file encrypted with the XYZ File Compressor Identifier 

security system. Use the UVW system to access it. For more The plaintext version (301) of the *FILE DATA* portion 

information, connect through the network to the World Wide 502fl may be pre-compressed with a commonly-available 

Web page located at: http:\\www.abc.com/help. Call me if data-compression system prior to encryption by E_unil 310. 

you need to modify this file. — Shawn." 45 Compression reduces file size and thereby reduces 

Label Presence Verifying Code encryption/decryption time. It also allows a storage medium 

When a file is firet opened, it is not always apparent (e.g., a magnetic disk) of fixed size to store more files. The 

whether a security label is or is not pre-fixed before the compressor identifier field 519 contains a compressor iden- 

*FILE DAIA* portion 502fl of the opened file. Specially- tifying code that indicates whether or not file compression 

located field 515 is provided for storing a code sequence that 50 has been conducted, and if so, by whidi compression 

is relatively unique with respect to its sequence and its system. The following coding system may be utilized: 0-No 

placement when compared to same-located data of non- compression, 1=PK.ZIP™, 2=Other compressor system, etc. 

secured files. This code is selected such that the probability Number of Activated ACER'S in this Label 

that an ordinary file will randomly contain the same, label- The number of users who are authorized to intelligibly 

presence verifying code in this same location 515 is rela- 55 access the *F1LE DATA* portion 502a of each given file 

lively small (e.g., less than 1 out of a thousand or more). 500 can vary over time and even firom one location to 

Field 515 is consulted as a sanity-check by label-using another. A given User__#J may be permitted to intelligibly 

software (see step 625 of RG. 6A) to better assure that a access the *FILE DAIA* portion 502(2 of a file stored in one 

label is indeed present. on-network server but at the same time that same given 

Major and Minor Version Numbers for this Label Type 60 User_#J may be denied permission to intelligibly access a 

The format of a file label 5026 is subject to change over replica *FILE DATA* portion 502a of a replica file that is 

time as new fields are added or some are removed. It is stored in another location. The attached FILE LABEL 

common practice to supply a version number having a major portion 5026 of each *FILE_N DATA* portion 502a 

portion and a minor portion as indicated by respective fields defines the access rights for that *FILE_N DADV* portion 

516a and 5166. The major version number is incremented 65 502a. 

each dme major revisions are made to the format of the file Aside fiom the right to intelligibly read the *FILE_^ 

label 5026. The minor version portion 5166 is incremented DATA* portion 502a, one or more users may be enabled. 
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through further access rights provided in their respective 
ACER'S (see field 557 of FIG. 5B), to modify the current 
label portion 5026 and, in so doing to add active ACER*s for 
newly-authorized users. The ACER of an already-authorized 
user is referred to here as an * activated' ACER. As will be 5 
seen shortly, oot-yet-authorized users who wish to have their 
respective ACER'S inserted into the file label SQ2b as 
activated ACER*s may request such action by writing an 
ACER Add-on Request block (e.g., 581) into a buffer zone 
580 of the label. Each ACER Add-on Request block (e.g., 10 
581) preferably has the same format as an activated ACER 
with the exception that field 565 (FIG. SB) does not yet 
include a privately-encrypted copy *Sys_J)_key* 565a of 
the Sys_D_key 316. The preferred format for and use of the 
ACER Add-on Request block (e.g., 581) is further described 15 
below. 

Field 521 contains a signal representing the number of 
presently 'aaivated' ACER'S in this label portion 502b, The 
activated ACER'S are denoted as 571 through 579 in FIG. 
5A. When a next-appended, ACER Add-on Request block 20 
(e.g., 581) is converted into an * active' ACER, the number 
in this field 521 is incremented by one. Label-using software 
may use the contents of this field 521 to determine which 
ACER_#n 579 is the last ' active' ACER within the file label 
5026. 25 
Length of Activated ACER'S in this Label 

In one embodiment, each ACER includes a privately- 
encrypted (e.g., an RSA-encrypted) version, *Sys_D__key* 
of the system D ^ey. The length of the encrypted version 
*Sys_D_key* may vary from one instance to another and 30 
the length of each ACER may vary accordingly. Field 522 
contains a signal that indicates the total length of the 
activated ACER'S 571-579 in this label 5026. Field 522 can 
also be viewed as a relative address pointer to the starting 
point 580 of the label buffer zone 580-589. 35 
OTF Recryption Flag 

This field 524 contains an *On-Tlie-Fly' recryption algo- 
rithm flag. When the OTF recryption algorithm is used, as 
described in the above-referenced U.S. patent application 
Ser. No. 08/586,511 [Attorney Docket SYMA1015], field 40 
524 is consulted by the OTF routines. One function of the 
OTF recryption flag 524 is to indicate whether or not the 
present file 500 is a 'special' file that should be excluded 
from automatic, on-the-fly decryption and re-encryption. 
Initial Vector 45 

For some decryption algorithms such as DES, the D_unit 
320 needs to be supplied with an 'initial vector' or a 'seed' 
in addition to being supplied with the Syst6m_J)^ey** 
326. Field 530 stores an initial vector to be used with DES 
or another seed-primed decryption algorithm. 50 
UUID of Last Modifier of this Label 

This field 531 contains the UUID (or other User_ID) of 
the last user to modify the present label portion 5026. There 
are at least two uses for this label-contained identification 
531 of the last label-modifier. First, it lets system adminis- 55 
tratois easily conduct automatic audits which determine who 
is responsible for the latest version of each file label 5026 of 
each given file 500. 

Second, the last label-modifier identification 531 may be 
used for automatically fetching the public D__key of that last 60 
label-modifier. The fetched public D_key is used for 
authenticating the integrity of the present label 5026 based 
on the digital signature stored in field 540. 

In one embodiment, the UUID of field 531 is submitted to 
the P/P key-pair distributor 390 of FIG. 3. In response, the 65 
P/P key-pair distributor 390 supplies the public key of the 
identified last-modifier. The released public key is used to 
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decrypt the digital signature stored in field 540. The result is 
then compared against a hash of 'signature-covered' por- 
tions of the label 5026 to assure that there have been no 
unauthorized dianges made to the label. 
Date of Last Modification of this Label 

This field 532 stores the date of the last modification of 
the present label 5026. 

Users may elect to change their public/private key pairs 
on random days for security reasons. In the process of 
authenticating the present label 5026 with the digital signa- 
ture stored in field 540, the date of last modification 532 
should be supplied to the P/P key-pair distributor 390 
together with the User_ID of field 531 so that the appro- 
priate public key is released for authenticating the present 
label. 

UUID of Initial Creator of this Label 

Field 535 contains the UUID (or other Uscr_JD) of the 
user who initially created the present label portion 5026. 
This information may be used for generating automatic audit 
trails. Usually, the initial creator of the label 5026 will have 
his ACER in the first active ACER position 571. If needed, 
a system administrator may obtain a copy of the system 
D_key 316 from this first ACER_#1 571, by first fetching 
the UUID of field 535 (the User_ID of the initial creator) 
and the initial creation date stored in field 536. The system 
administrator may then obtain that user's private D_Jcey 
firom unit 390 and may apply it to uncover the *Sys_D„ 
key* stored in field 565 (FIG. 5B). 

The initial label-creator (535) is usually also the user who 
created the initial version of the *FILE DATA* portion 502a 
and perhaps the first few modified versions of that portion 
502fl. That user may have archived (and secured) copies of 
the initial *FILE DADV* portion 502a as it existed prior to 
subsequent modifications. In certain circumstances, it might 
be desirable to obtain that archived initial copy. For 
example, it might be desirable to determine what changes 
have been made. The UUID 535 of the initial creator may 
help in locating the initial copy and perhaps the first few 
modified versions of that portion 502^. 
Date of Initial Creation of this Label 

This field 536 contains the date of the initial creation of 
the present label portion 5026 prior to all subsequent modi- 
fications. As indicated above, in certain circumstances it 
may be desirable to obtain the public or private keys of the 
initial creator and to apply them to an archived version of the 
present file. The date 536 of initial creation may be used to 
make sure that the correct version of that user's public/ 
private keys arc fetched from the key distributor 390. 
Last Modification Date of Postfixed File 

The post- fixed *FILE DATA* portion 502a may be modi- 
fied independently of the label portion 5026. This field 539 
indicates the last date of modification of the post-fixed 
*FILE DATA* portion 502a. It helps a group of authorized 
users to know what version of the file data they are working 
with. 

Digital Signature by Last Modifier of this Label 

The application of digital signatures for authenticating 
stored data is fairly well known. 

In brief, a secured hash function is applied to the 'covered' 
portions of the signed-over data. The hash result is asym- 
metrically encrypted with a private key of an authenticating 
entity. Thereafter, the signed-over data is authenticated by 
reapplying the secure hash function to the 'covered' data 
portions. The digital signature is decrypted using the 
authenticating-entity's public key. The decryption result is 
compared against the hash result If they match, a certain 
amount of confidence is created respecting the authenticity 
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of the signed-over data. If they do not match, this indicates respective active ACER 571-579 within the access control 

that the signed -over data has been tampered with and is thus table 571-579, fetches an included, but privately-locked 

no longer tnistable. *Sys_D_Jcey* 565a, and decrypts this code 565a with 

In the case of secured file 500, the digital signature of field his/her private key (394) or password in order to gain 

540 'covers' the entire label portion 502^ except for the 5 possession of the Sys_J)_Jc6y** signal 326. Signal 326 is 

signature itself 540 and the extension buffer zone that then used for decrypting the nonsensical data contained 

extends from point 580 through point 589. The authenticat- between points 590 and 599 of the *FILE DATA* portion 

ing entity v^o appUes their signature over this covered data 502a. 

is the last label modifying entity identified by field 531. The Referring to FIG. 5B, a preferred data structure 550 for 

private key of the so-identified last label-modifier (531) is 10 both an active ACER (e.g., 571) and an ACER Add-on 

used for genera ting the digital signature contained in field Request (e.g., 581) is now described. 

540. The public key of this same last label-modifier (531) is Length of this ACER_#X 

used for authenticating the signed-over label 5026. xhis first field 551 of the ACER data structure 550 

The label-using software preferably authenticates the contains a signal indicating the total length of the present 

'covered' portions of the label 5026 with the digital signa- ^5 ACER_#X (in terms of bits, bytes, or as otherwise 

ture 540 to assure that the label had not been improperly appropriate). Field 551 may also be viewed as a relative 

tampered with before using that label. address pointer to the end of the present ACER and as 

Active ACER_#1 through ACER„#n ^ pointer to the beginning of the next ACER_#X+1 (570). 

Blocks 571-579 respectively define the user records of an UUID of User_#X associated to this ACER or Other Access 

Access Control Table (ACO that provides the functional- 20 to This ACER 

ities generally described with respect to FIG. 4. In one in one embodiment, the next field 552 contains the UUID 

embodiment, each ACER, 571, 572, . 579, is formatted in or other identification of the User_#X that is associated with 

accordance with the structure 550 shown in FIG, IB. the current ACER_#X. The contents of this user-identifying 

Extension Buffer space field 552 are submitted to the P/P key-pair distributor 390 in 

The end of the last active ACER_#n 579 defines the 25 order to fetch this user's private D_key 394. 

beginning point 580 of the extension buffer space. This Iq another embodiment, field 552 contains an ACER- 

buffer space ends at location 589. The extension buffer space access password code that, when given by any generic user 

580-589 is generally empty and may be used for adding new (irrespective of that user's UUID), identifies the current 

active ACER's to the label portion 5026 without need for a ACER and grants that user access to this ACER and more 

rewrite of the *FILE DATA* portion SOZa. 30 specifically to the plaintext version of the *Sys_D_key* 

The extension buffer space 580-589 is not covered by the code 565a stored in below described field 565. The ACER- 

digital signature 540. As such, not-yet-authorized users may access password code is preferably at least as long as one of 

insert material into this buffer space 580-589 without inter- the earlier described UUID's. The special-handling code of 

fering with the functionaHty of the remainder of the label field 555 may indicate whether present field 552 contains a 

5026. 35 uun> or other identification of the User_#X or whether 

In one embodiment, the extension buffer ^ace 580-589 present fieki 552 contains an ACER-access password code, 

is used by unauthorized users to submit ACER Add-on xhe ACER-access password code may be used in a 

Requestssuch as shown at 581 and 582. Each ACER Add-on following scenario: User_#A wants to transmit data 

Request 581, 582, etc., preferably has the same structure as securely over an open channel to User_#B. But User_#B 

the model ACER 550 shown in FIG. 5B with the exception 40 does not have a UUID or other identification of who he/she 

that region 565 stores the requesting user's public E_Key is, installed on his/her computer. User_#A creates a generic 

5656 instead of an encrypted *Sys_JC)_Jcey* 565a. ACER within the FILE LABEL portion 5026 where field 

The file label 5026 may be periodically scanned by 552 contains a randomly-generated sequence defining the 

authorized users who have label-modification rights. One of ACER-access password code. User_#A then sends the 

these so-authorized users may scan the ACER Add-on 45 secured file (having the *nLE_N DAD\* portion 502a and 

Requests 581, 582, etc.; and if they so choose, such autho- the just-modified FILE LABEL portion 5026) over the 

rized users may modify the label 5026 so as to convert one channel to User_#B. User_#A sends the ACER-access 

or more of the ACER Add-on Requests 581, 582, etc. into a password code to Usct_#B over a separate channel (e.g., by 

respective one or more active ACER*s. In this way, not-yet- telephone at a pre-arranged time). User_#B then supplies 

authorized users who feel they should be granted access to 50 the received ACER-access password code to his/her com- 

thc secured *FILE DATA* portion 502a may submit their puter and the label-using software locates the corresponding 

requests by way of the file's label portion 5026. Multiple ACER and obtains the plaintext version of the ♦Sys_D_ 

Add-on Requests can be centrally collected in the extension i^ey* code 565a. 

buffer space 580-589 and all acted upon at one time or on Referring to FIG. 3, for this User_#A/#B scenario, signal 

a request-by-request basis. 55 354 is the ACER-access password code which User_#B 

*FILE DATA* portion suppHes to his/her computer. Label-searching engine 365 

As indicated above, the ♦FILE DATA* portion 502a scans the plurality of ACER'S in the FILE_J4 LABEL 

begins at a point 590 that coincides with or follows the end portion 3026 for an ACER having the matching ACER- 

589 of the extension buffer space 580-589. The material access password code in its field 552. When found, the 

between the begirming 590 and end 599 of the *FILE go *Sys_D_key* signal in that matching ACER is passed 

DATA* portion 502a is encrypted with the system E_JCey through D_unit 340 to produce the System_D_key** 326. 

315, and as such it is depicted to have the following yhe User_#B key that is applied to key-input 345 of the 

nonsensical form: D_unit 340 for this scenario can be any that is predefined by 

*&^%$#$%*&^%$#!##S%"&%%*0>??<S$* User_#A and relayed to User_#B over a relatively secure 

♦&"%$#$%*&*%$#!##$%"&%%''(}>??<S$* 65 channel. The key that is applied to key-input 345 is really 

To gain intelligible access to the information contained this ACER'S private D_Jcey rather than that belonging 

between points 590-599, an authorized user locates his/her specificaUy to User__#B. 



07/02/2003, EAST Version: 1.03.0002 



5,9^ 

21 

If desired, the special-handling code of field 555 may 
cause the generic ACER to be scorched out of the label 302i) 
after the plaintext version 326 of the *Sys_D_key* code is 
released one-time from that generic ACER. The latter 
optional process thereby makes that generic ACER a one- 
time useable carrier of the *Sys_JD__key* code. 
Date of Creation of User_#X's P/P 

As indicated earlier above, users may occasionally change 
their public-private key pair. The private key that was used 
to CTeate the *Sys_D_key* code 565a has a certain date of 
creation associated with it. Field 554 stores an indicator that 
identifies the dale of creation of User_#X's public/private 
key pair, as applied to code sequence 565a. If User_X has 
changed his/her P/P key-pair after the date of creation of this 
ACER_#X, the data in field 554 will indicate that a previous 
P/P key -pair needs to be used for imcovering (unlocking) the 
information within the *Sys_J)_Jcey* code sequence 565a. 
Special Handling Code for this ACER 

A variety of specialized, label-using software routines 
may be developed for reading the contents of a file label 
S92b and using it as appropriate. One example was already 
given above with respect to field 552. The present field 555 
cooperates with the specialized, label-using software rou- 
tines for providing specialized functions on a per-ACER 
basis. 

By way of further example, specialized, label-using soft- 
ware may be provided for displaying various sections of a 
label 5026 to an inquiring user by way of a screen or by other 
means (e.g., a printout). An inquiring user might wish to 
know, for example, who else is authorized to gain intelligible 
access to the attached *FILE DATA* portion 502fl, and 
perhaps what are the access rights of each such user. 

There may be instances where the system administrator 
wishes to hide from general viewing the identities of certain 
types of authorized users. The special handling code stored 
in field 555 cooperates with the label-using program to 
provide special handling fiinctions for certain ACER'S such 
as, but not limited to, not displaying the identity of the 
authorized user for whom this particular ACER has been 
created. Another special handling function might be, not 
displaying certain access rights of the user for whom this 
ACER has been created. 

The usefulness of such special handling codes (555) may 
be understood by considering the following example. 
Assume a corporate entity hires three employees 
(Employees 1-3), assigns them to work on material con- 
tained within the secured *FILE DATA* portion 5Q2<2, but 
authorizes only Employee #2 to have label-modifying rights. 
Suppose a misunderstanding develops between Employee 
#2 and the corporate entity. Suppose Employee #2 decides 
to modify the label such that Employees #1 and #3 are 
locked out. Employee #2's intent in so doing is to hold as a 
hostage, the now non-accessible *File Data* portion 502fl 
until the corporate entity compHes with certain demands. 

However, unbeknownst to Employee #2, there was 
another authorized user with file-access and label-modifying 
powers. The label-using software never displayed the pres- 
ence of that other user because that other user's ACER had 
its special handling code of field 555 so encoded. In this 
example that non-displayed other user is the corporate entity. 
A special handling code was included in a fourth ACER to 
hide the existence of the fourth ACER from Employee #2. 
Now the corporate entity can instead lock-oul Employee #2 
by appropriately modifying the label, hand over secondary- 
modification rights to another employee, and thereby avoid 
being taken hostage through the security system appUed to 
its own data. 
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The special handling code 555 may also be used to 
identify a special ACER by which government agencies or 
other specially-authorized entities may gain access to the 
secured *FILE DATA* portion 502fl using a backdoor key. 

5 Major & Minor Version Numbers for this ACER 

As with the format of the enveloping label 5026, the 
format for an ACER of a given user may be modified in a 
major or minor way. Fields S56a and 5566 respectively 
contain the major and minor version numbers of the current 

10 ACER and may be referenced by label-using software to 
determine what specific format is being used by each ACER. 
(A file label may contain ACER'S having different formats.) 
Read & Write Access Rights of this User_#X 

Some users may be given full read and write access rights 

IS to all parts of the secured file 500 including the label portion 
5026 and the data portion 502a. Other users may be given 
read-only access rights with respect to the label portion 
5026. The latter users are thus not able to modify the label 
portion 5026. 

20 Field 557 contains code defining the various read and 
write access rights of this User_#X at least with respect to 
the label portion 5026, and optionally also with respect to 
the *DArA* portion 502a. (The latter access rights may be 
alternatively or additionally defined by the operating sys- 

25 tem's permissions flags.) 

Sys_D_JK6y Covered by User_JC Private or PassWord 
Key? 

In one alternate embodiment of the present invention, 
units 330/340 (FIG. 3) define a symmetric encryption/ 

30 decryption system instead of a non-symmetric one. In such 
a case, a same password-key is applied to key-inpuls 335, 
345 instead of the respective public and private keys. The 
applied password-key may be the same as the User 
#X_4)assword 361 submitted to unit 360 or it may be 

35 different. 

In yet another alternate embodiment of the invention, 
each of units 330 and 340 (FIG. 3) has an additional 
algorithm-selection input (shown as an unreferenced 
arrowhead) similar to the algorithm select-inputs 317, 327 of 

40 units 310 and 320. In this alternate embodiment, the E _/D_ 
units 330/340 are programmably configurable to operate 
either as a selected, symmetric encryption/decryption sys- 
tem or as a selected, non-symmetric (public/private) 
encryption/decryption system. 

45 The private/password key -specifying field 560 indicates 
whether the *Sys__D„key* code sequence 565a is covered 
with the present User_X's private key or that user's pass- 
word key. If field 560 indicates the use of a private key, then 
the user's private D_Key 25>4 is applied to input 345 of 

50 D_unit 340 and unit 340 is configured to function as part of 
a public/private key-pairing system. If field 560 indicates, on 
the other hand, that the user's password key had been used, 
that user's password key is applied to key-input 345 and 
D_unit 340 is configured to operate as part of a symmetric 

55 encryption/decryption system 330/340; Region 565 can 
therefore be used to distribute the Sys_D_key** signal 326 
to one or both types of users, namely, those that have 
public/private key-pairs and those that do not. The latter 
users would instead use their individual password keys to 

60 uncover the *Sys_D^ey*. 

User_DAS (Selected Private Etecryption Algorithm) 

In one embodiment, field 561 stores a User_DAS signal 
(shown in FIG. 3 as an unreferenced arrowhead and analo- 
gous to 327). When fetched, the signal in field 561 is applied 

65 to an algorithm-select input (unreferenced) of D_unit 340. 
The following coding system may be used: 0=No 
decryption, 1=RSA public/private, 2=DES (symmetric). 
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3=Blowfish, etc. When units 330/340 define a symmetric 
encryption/decryption system, the User_DAS signal may be 
the same as the corresponding Uscr_BAS signal that would 
be applied to an algorithm-select input (shown in FIG. 3 as 
an unreferenced arrowhead and analogous to 317) of E_unit 
330, Field 561 of this embodiment therefor defines what 
decryption algorithm is to be applied to a below-described, 
code-containing field 565a. 

In another embodiment, the decryption algorithm of 
D_unit 340 is otherwise established and field 561 stores the 
*SysDAS* signal 318a (FIG. 3). When fetched, the signal in 
field 561 is first uncovered by the user's private D_key (or 
by his/her private password) and thereafter applied by path 
328a to input 327 of D„unit 320. 

Length of Key-containing Code in Next Field included in 
this ACER 

Field 562 contains a signal indicating the length (in bits or 
bytes) of the key-containing code found in the next field 565. 
Tliis length-specifier 562 assists the label-using software in 
determining the length of valid key-containing code in next 
field 565. 

*Sys_D_Key* or User_#X Public Key 

Field 565 may contain two different kinds of key- 
containing code. In one instance, field 565 holds the *Sys„ 
D_key* code 565a and the present ACER_#X is an active 
ACER. 

Id an alternate instance, field 565 holds code 5656 where 
the latter is the public E_JCey of a request-submitting 
User_#X. In this alternate instance, structure 550 may 
function as an ACER Add-on Request such as shown at 581, 
582 (FIG. 5A). If and when the add-on request is granted, the 
user's public E__Key 5656 is fetched fi-om field 565 and 
submitted to key-input 335 of E_unit 330. The Sys__J)_Jcey 
signal 316 (or signal 326) is applied to input 331. The result 
332 is then overwritten into field 565. Appropriate modifi- 
cations are made to fields 521, 522, 531, 532 and 540 of the 
label 5026, and the add-on request is thus transformed into 
an active ACER. 

If the extension buffer space 580-589 approaches an 
overflow condition, the length of the label portion 5026 may 
be increased by modifying field 511. The *FILE DATA* 
portion 502a will generally have to be rewritten in such a 
case to make room for the lengthened label portion 5026. 
Optional End Space Buffer 

Like the enveloping label 5026, each ACER 550 may 
optionally include an end space buffer region 569 for accom- 
modating internal growth of the ACER data structure 550. 
When the optional end space buffer 569 is included, the 
internal structure of a given ACER 550 may be modified to 
add new fields without having to rewrite the ACER'S of 
other users. 
NEXTACER_#X+1 

As shown, the next ACER_#X+1 follows the end of 
ACER_#X. Given the use of version numbers and the 
optional end space buffer 569, the next ACER„#X+1 (570) 
may be identical to or different in format from the preceding 
ACER_#X (550). 

Referring to FIGS. 6A-6B, a label-using process 600 in 
accordance with the invention is now described. 

At step 601, the computer system is powered-up or 
rebooted. At step 610, a given User_#X logs into the system 
and supplies his/her password. This User_#X*s password 
361 is appUed to the identification authenticator 360 of FIG. 
3. Upon entry of an acceptable password and performance of 
optional, other identification authenticating tasks, unit 360 
releases plaintext versions of the user's private D__Key 394 
and UUID 393 into the volatile memory (e.g., RAM) of the 
system. This release is indicated by step 611. 
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At Step 620, User_#X, or an application program that the 
user is nmning, submits a file-access request to the comput- 
er's operating system (OS). Typically, this is in the form of 
an OPEN FILE request followed by the name of the file to 
5 be opened. The label-using program intercepts this request 
to the OS and redirects control to next step 622. 

At step 622 the starting portion of the requested file is read 
from di^ (or another appropriate media) and stored into the 
system volatile memory (RAM). The just-read portion may 
or may not contain a file security label such as 5026 of FIG. 
5A. 

At step 625, a test is performed to determine if a label is 
present. In one embodiment, the location corresponding to 
field 515 is scaimed for label-presence verifying code. Lack 
of such a code indicates that a label is not present. 

15 At decision step 627, the OS intercepting routine is exited 
if it is determined that a label is not present. The exit path 
629 continues with a normal OS handling of the OPEN FILE 
request. It is assumed that the requested file is not secured 
because it does not have a label, and as such, the file's 

20 contents can be intelligibly accessed without decryption. 
If a label has been detected, step 627 passes control by 
way of path 628 to step 630. 

In step 630, the Access Control Table (ACT) is scanned 
for an ACER containing a user identification matching that 

25 of the presently logged-in User_#X. 

At decision step 635, if no matching user identification 
had been found within the Access Control Table (ACT), it is 
decided that this user is not authorized to access the 
requested file. The intercept routine is exited by way of path 
639 and the routine passes a 'failed* OPEN attempt indicator 
to the operating system. The operating system then handles 
the failed OPEN as appropriate. 

If within decision step 635 it is determined that a match- 
ing user identification (e.g., a matching UUID) had been 
found, then the intercept routine continues along path 636 to 

35 step 640 (FIG. 6B). 

At step 640, a field such as 560 (FIG. 5B) of the ACER 
is consulted to determine whether die key-containing code 
565a is covered with the tiser's private key or with the user's 
password. If the answer is neither, path 643 is taken back to 

40 step 635 (FIG. 6 A) and the intercept routine is exited with 
a failed-OPEN indication by way of path 639. 

Path 641 is followed if step 640 determines that an 
asymmetric private key has been used as the private user 
key. Path 642 is followed if step 640 determines that a 

45 symmetric password has been used as the private user key. 
In step 651 the user's private D-key is obtained from the P/P 
key-pair distributor 390 by submitting the user's UUID to 
unit 390. Alternatively, for path 642, the user's password key 
is obtained in step 653. 

50 In step 652, the key-containing code 'Sys^D^Jcey* 565a 
is asymmetrically uncovered using the user's private D-key. 
Alternatively, if path 642 had been taken, the key-containing 
code 565fl is symmetrically uncovered with the user's 
password key in step 654. 

55 At subsequent step 660, the uncovered Sys_D _Jcey** is 
applied to input 325 of D_imit 320 for decrypting the *FILE 
DATA* portion 502a of the requested file. 

Following successful decryption, step 670 returns control 
to the operating system for normal handling of the remainder 

60 of the OPEN FILE request. In one embodiment, the label- 
using program 600 forms a complementary part of the 
SYSTEM FOR AUTOMATIC DECRYPTION OF HLE 
DATA ON A PER-USE BASIS as disclosed in the above- 
referenced U.S. application Ser. No. 08/586,511. 

65 The above-described methods and physical implementa- 
tions of data structures may be practiced in a variety of 
settings. 
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FIG. 7 is a block diagram of a computer system 700 that 
may be used in accordance with the iavention. Computer 
system 700 iacludes a system bus 710 coupling a system 
memory 740 such as a random access memory (RAM) to a 
plurality of other system resources including a system CPU 
720, system I/O 760, an intersystem data conveyance means 
730 (e.g., diskette or CD drive), and a nonvolatile disk 
subsystem 750. Portable media 735 (e.g., a floppy diskette or 
a CD-ROM disk) is removably and operatively couplable 
with system 700 by way of the intersystem data conveyance 
means 730. 

The system memory 740 may comprise assorted types of 
high-speed random access devices into which immediately 
executable code may be stored. System memory 740 can 
include one or more of static RAM (SRAM), dynamic RAM 
(DRAM), and other like devices. Typically at least part of 
the system memory 740 is volatile, meaning data is lost and 
must be rewritten when power is lost. It is not outside the 
contemplation of the invention to have system memory 740 
defined partly by non-volatile random access memory 
devices such as flash EEPROM. Often the computer system 
700 will include a small boot ROM (Read Only Memory, not 
shown) coupled to the CPU 720 for power-up and other 
basic re-bootings of the system. 

Plaintext versions of confidential information such as that 
of FILE_N DATA** 303 (FIG. 3), System_D_Jcey** 326 
and private D_koy 394 are preferably placed only in the 
volatile portions of system memory 740 for short-term use 
as needed, and thereafter immediately scorched (erased to an 
extent that removes the possibility of simple recovery). 

When system 700 boots-up, various files are automati- 
cally loaded from the disk subsystem 750 or from elsewhere 
(e.g., from system I/O 760) into system memory 740 to 
thereby create a coUection of data structures within system 
memory 740. These data structures normally include execut- 
able instruction code (e.g., 745) that can be immediately and 
usefully executed by a responsive data processing unit such 
as the illustrated central processing unit (CPU) 720 of FIG. 
7 or by non-oentralizcd multiple data processing units (not 
shown) that may be further or alternatively coupled to bus 
710. 

The system I/O module 760 uses bus 710 for transferring 
data between one or more of the iUustrated portions of 
system 700 and external devices. In one embodiment, the 
system I/O module 760 may couple the iUustrated system 
bus 710 to a variety of external resources such as a user 
terminal (e.g., keyboard and monitor), a local area network 
(LAN), a wide area network (WAN) and/or to other external 
data transceiving and processing means 765. 

The data conveyance means 730 can be defined by data 
transfer devices such as floppy diskette drives, tape drives, 
CD-ROM drives and other such means by which data 
recorded on transportable media 735 can be brought into 
system 700 or copied and carried away from system 700. 

The disk subsystem 750 typically includes a drive (not 
separately shown) and a nonvolatile data storage medium 
(not separately shown) onto which data may be stored and 
from which data may be retrieved. The disk data storage 
medium may be in the form of a magnetic hard disk, or a 
floppy diskette, or a re-writable optical disk, or other such 
non-volatile, randomly accessible, re-writable media. ROM 
or Flash EEPROM may be alternatively used in carrying out 
some or all of the nonvolatile data storing functions of the 
disk subsystem 750. 

Data is recorded on the disk subsystem 750 to define a 
directory structure 751 and a plurality of files (not all shown) 
such as automatic boot-control files 752, and other nonse- 
ciu'ed files such as 753. 
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Directory structure 751 points to, and defines the storage 
oiganization of each of the stored files. By way of example, 
the boot-control files 752 may be defined as being contained 
in a root directory (such as c:\in MS-DOS™ parlance). The 

5 unsecured other files 753 may be defined as being contained 
in a first subdirectory (such as c:\u in MS-DOS'"" parlance). 
Yet other files such as the illustrated files 745 and 756 may 
be defined as being contained in a second subdirectory 760 
(such as c:\s in MS-DOS™ parlance). One or more of the 

10 files such as 754 and 756 are referred to herein as secured or 
encrypted files. Secured files 754-756 are preferably defined 
in accordance with the file data structure 500 of FIGS. 
5A-5B. 

Directory stmcture 751 may further store various levels of 

15 OS-defined permission flags with respect to each file. These 
OS-defined permission flags are independent of the access 
right signals contained in area 557 of FIG. 5B. Although not 
shown, the disk subsystem 750 may temporarily contain 
plaintext file copies derived from one or more of its 

20 encrypted files, 754-756 by way of decryption. 

Although not fiirther explicitly shown in FIG .7, disk 
subsystem 750 may further store: (a) software instructions 
for causing CPU 720 to carry out all or at least part of the 
machine-implemented, data processing functions described 

25 with respect to FIGS. 3 through 6B, and (b) secured versions 
of various keys such as the *Sys_X)_Jc6y*. 

All or various parts of the data recorded on the disk 
subsystem 750 may be brought into subsystem 750 or copied 
out from subsystem 750 through a variety of means includ- 

30 ing data conveying means 730 and/or I/O means 760. The 
latter collection of pathways may include but are not limited 
to: floppy diskettes, compact-disks (CD-ROM), tape, and 
over-a-oetwork downloading by a file server computer or the 
like. 

35 Given that data in stored files such as encrypted files, 
754-756 may become available to unauthorized users 
through a variety of ways (as already described above), it is 
desirable to keep as much of this stored data in an encrypted 
form (ciphertext form) except for times when it is being 

40 legitimately used by authorized users. The legitimate plain- 
text versions are temporarily kept in system memory 740 as 
explained above and scorched as soon as their continued 
existence no longer serves the needs of an authorized user. 
It is desirable, on the other hand, to make the encrypted 

45 *DATA* portions (754a, 756^) of secured files (754, 756) 
intelligibly accessible to authorized users, wherever they are 
located, in as easy a manner as possible without compro- 
mising security. 

By way of example, suppose system 700 is an in-office 

50 machine and an authorized User_#X wishes to take a 
ciurent copy 7542 of secured file 754 home to work with on 
his/her home computer. Although not shown, the home 
computer can have the same basic structure 700 as that of the 
in-office computer with the exception that a current copy of 

55 file 754 does not resides within the home computer. The 
home computer (not shown) is occasionally referenced 
herein as 700'. 

The copy 754.2 can be made by passing signals repre- 
senting file 754 from disk subsystem 750, over system bus 

60 710 and through data conveyance means 730 onto the 
transportable (nonvolatile) media 735. The copied encrypted 
'DATA* portion 754^.2 is equivalent to the original 
encrypted *DArA* portion 754^. The copied LABEL por- 
tion 7546.2 is equivalent to the original LABEL portion 

65 7546- In addition to the copied file 754.2, User_#X may 
also record onto transportable media 735, label-using soft- 
ware instructions that are targeted for his/her home com- 
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puter for causing that home computer 700' to function in 
accordance with the systems of FIGS. 3-6B. Such label- 
using software instructions are represented by the on-media 
data 736 of FIG. 7. 

If for some reason User_J^X loses possession of trans- 5 
portable media 735, the *DArA* portion 754a.2 recorded 
thereon continues to remain scciire by virtue of it being still 
encrypted and because the LABEL portion 7S4b2 does not 
contain a plaintext version of the Sys_D_Key sigjial (316) 
that is needed for unlocking *DArA* portion lS4a2. lo 

Once at home, authorized User_#X can unlock *DArA* 
portion 754fl.2 by supplying his/her private D_key (or 
password key) to uncover the *Sys_D_key* signal stored 
in his/her respective ACER within LABEL portion 7546 J. 

If our exemplary User__#X has file-modifying rights, that IS 
User__#X may mcxlify the plaintext information of *DArA* 
portion 754a.2 on his/her home computer, re-encrypt it with 
the System_E_key (315) and overwrite area lS4a2 of the 
transportable media 735 with the new version. 

If our exemplary User_#X has label-modifying rights, 20 
that User_#X may choose to scan the extension buffer space 
580-589 (FIG. 5 A) while working on his/her home com- 
puter 700', and to grant intelligible access rights to not-yet- 
authorized users who have appended their ACER Add-on 
Request blocks (e.g., 581) into buffer space 580-589 over a 25 
recent time period. The intelligible access rights are granted 
by transforming the ACER Add-on Request blocks (e.g., 
581) into active ACER'S as explained above. When done, 
our exemplary User_#X overwrites area 7S4b2 of the 
transportable media 735 with the new version of the label. 30 

On return to the office, our exemplary User_#X inserts 
the at-home modified transportable media 735 into drive 730 
and overwrites the old version of file 754 with the new 
version 754.2 now stored on media 735. 

A next, authorized user (User_#X+l) can now iotelligi- 35 
bly access the encrypted *DArA* portion 754a (or modified 
754a .2) and perform further work on that portion 754fl (or 
on the on-diskette, modified portion 754a.2) as desired. 

If an old private D__key or private password of a given 
User_#X+2 is deemed to be compromised for some reason, 40 
his/her respective ACER (e.g., 572) should be scorched out 
of the LABEL portion 7546 on the office machine and also 
out of the corresponding label portions of all offrsite copies 
(e.g., 7542) of the file. A new ACER that is secured by a 
new private D^ey or a new private password can then be 45 
created for this User_#X+2. All other users can continue to 
transparently use their old private D Jccys or private pass- 
words without concern for the compromised condition of 
User_#X+-2*s old private D_key or private password. 

This is in sharp contrast to what would have happened if so 
the multi-user shared-key system 100* of FIG. IB had been 
used. There, in FIG. IB, if a key-compromising incident 
occurs to one user, all users must be given a new multi-user 
shared-key. This inconveniences all the users. The process of 
mass-distributing the new key itself creates a new possibility ss 
of compromise. 

Although the above discussion in relation to transportable 
media 735 described the conveyance of a file copy 754.2 
from one computer 700 to a home computer fOO* (not 
shown) by way of the so-called sneaker-ware path (by using 60 
transportable media 735 to convey the file between the two 
machines), a similar process can be carried out through 
signal transmission by way of network connection 765 
between the two machines 700 and 700' (the latter not 
shown). The signal transmission path 765 does not have to 65 
be a secured channel because the transmitted *DArA* 
portion 754a.2 is protected by encryption. The transmitted 
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*Sys_D _Jcey* is also protected by private encryption 
within the respective ACER of each authorized user. 

As such, a convenient and secure system has been 
desdribed for allowing multiple users to share access to a 
given file and for easily managing the distribution of access 
keys to various users. 

Given the above disclosure of general concepts and 
specific embodiments, the scope of protection sought is to be 
defined by the claims appended hereto. 

What is claimed is: 

1. A machine system for maintaining confidential infor- 
mation generally in encrypted form while allowing for 
intelligible access to such confidential information by miil- 
tiple users, said machine system comprising: 

(a) a first data conveyance means for conveying digitized 
first data representing said encrypted form of the con- 
fidential information and for further conveying digi- 
tized second data representing an associated label, 
(a.l) wherein said encrypted form of the confidential 

information is producible by a first encrypting pro- 
cess using a finit encryption key, 
(a .2) wherein said second data contains two or more 
encrypted versions of a first decryption key, said first 
decryption key being a signal that is applicable to a 
first decrypting process for decrypting the encrypted 
form of the confidential information and for thereby 
producing a plaintext form of the confidential 
information, 

(a.2a) wherein a first of said two or more encrypted 
versions of the first decryption key is decipherable 
by a first user key, the first user key being asso- 
ciated with a first user among said muhiple users; 

(a .2b) wherein a second of said two or more 
encrypted versions of the first decryption key is 
decipherable by a second user key, the second user 
key being associated with a second user among 
said multiple users; 

(b) a first decrypting mechanism, operatively coupled to 
the first data conveyance means, for receiving the first 
data and for, upon a supplying of said first decryption 
key to said first decrypting mechanism, decrypting the 
first data into digitized third data representing the 
plaintext form of the confidential information; and 

(c) a second decrypting mechanism, operatively coupled 
to the first data conveyance means, for receiving at least 
one portion of said second data and for, upon a sup- 
plying of a corresponding one of said first and second 
user keys to the second decrypting mechanism, 
decrypting the at least one portion of said second data 
into digitized fourth data in accordance with a second 
decryption process so that said foiuth data includes the 
first decryption key, 

(c.l) wherein the second decrypting mechanism is 
operatively coupled to supply the first decryption 
key to the first decrypting mechanism; 

(c.2) wherein said second decrypting mechanism 
defines part of an asymmetric encryption/decryption 
system; 

(a.2c) wherein said first user key defines a private 

part of a first public-private key pair associated 

with said first user; and 
(a.2d) wherein said second user key defines a private 

part of a second public-private key pair associated 

with said second user. 

2. A machine system according to claim 1 wherein: 
(a.3) said first data conveyance means includes digital 

data storing means for storing said digitized first and 
second data. 
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3. A machine system according to claim 2 wherein: 
(a.4) said first data conveyance means further includes 

digital data transmitting means for transmitting said 
first and second data by way of a nonsecure data 
transmission path. 

4. A machine system according to claim 2 wherein: 
(a.3b) said second data contains a plurality of Access- 
Control-Entries Records (ACER's), 

(aJbi) a first of the plural ACER'S includes said first 

encrypted version of the first decryption key; 
(a.3bu) a second of the plural ACER'S includes said 

second encrypted version of the first decryption key; 
(aJbiii) the first ACER further includes a first user 

associating signal for associating the first ACER 

with said first user; 
(a3biv) the second ACER includes a second user 

associating signal for associating the second ACER 

with said second user. 

5. A machine system according to claim 4 further com- 
prising: 

(d) search means for scanning the plural ACER's within 
the second data, for locating therein a user-associated 
ACER that includes the user associating signal of an 
otherwise identified user, and for causing the corre- 
sponding encrypted version of the first decryption key 
to be supplied finom the user-associated ACER to be 
supplied to said second decrypting mechanism. 

6. A machine system according to claim 5 further com- 
prising; 

(e) identity authenticating means, operatively coupled to 
the seardi means, for authenticating the identity of an 
access-requesting user and for, upon successful authen- 
tication of the identity of the access-requesting user, 
supplying a corresponding user identification signal to 
the search means to thereby otherwise identify the 
access^iequesting user. 

7. A machine system according to claim 6 further com- 
prising: 

(f) a user-key distributing means, responsive to the iden- 
tity authenticating means, for supplying the associated 
user key of the otherwise identified access-requesting 
user to the second decrypting mechanism upon suc- 
cessful authentication of the identity of the access- 
requesting user by the identity authenticating means. 

8. A machine system according to claim 7 further com- 
prising: 

(g) a first encrypting mechanism, op>eratively coupled to 
the first data conveyance means, for receiving supplied 
data signals representing the confidential information 
and for, upon a supplying of a first encryption key to 
said first encrypting mechanism, encrypting the sup- 
phed data signals to thereby produce said first data and 
for further supplying said first data to the first data 
conveyance means; and 

(h) a second encrypting mechanism, operatively coupled 
to the first data conveyance means, for receiving at least 
one portion of confidential data to be conveyed by the 
first data conveyance means and for, upon a supplying 
of a user encryption key to the second encrypting 
mechanism, encrypting the at least one portion of said 
to-be-conveyed confidential data to thereby produce a 
secured portion of the second data so that said secured 
portion includes an encrypted version of the first 
decryption key, 

(b.l) wherein the second encrypting mechanism is 
operatively coupled to receive the user encryption 
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key of the access-requesting user from the user-key 
distributing means after successful authentication of 
the identity of the access-requesting user by the 
identity authenticating means. 
5 9. A machine system according to claim 8 wherein said 
first encrypting mechanism carries out a selectable one of a 
plurality of encrypting processes and responds to a supplied 
encryption algorithm select signal by carrying out a selected 
one of said plurality of encrypting algorithms as indicated by 
the encryption algorithm selecting signal 

10. A machine system according to claim 9 wherein the 
selectable encrypting processes include two or more mem- 
bers of the group consisting of: 

(1) XORring with a supplied keystream; 
15 (2) X__NORing with a suppfied keystream; 

(3) performing according to the Data Encryption Standard 
(DES); 

(4) performing triple-DES; 

(5) performing RSA RC4™; 

20 (6) performing RSA RCS*™; and 

(7) carrying out the Blowfish algorithm. 

11. The machine system of claim 6 wherein said user 
identifying signal is at least 40 bits long. 

12. A machine system according to claim 1 wherein: 

^ (a.3) the combination of said first encrypting process and 
said first decrypting mechanism defines a symmetric 
encryption/decryption system and said first decryption 
key is the same as said first encryption key. 

13. A machine system according to claim 12 wherein: 
(c.2a) said second decrypting mechanism operates in 

accordance with the RSA public/private algorithm. 

14. A machine system according to claim 1 wherein: 

(a. 3) said second data contains a plurality of Access- 
^5 Control-Entries Records (ACER*s) and each respective 
ACER includes: 

(a 3a) a first entry containii^ a respective, encrypted 

version of the first decryption key, and 
(a 3b) a second entry containing non-encrypted other 

40 

15. A machine system according to claim 14 wherein said 
non-encrypted other data includes: 

(a.3bi) an identification of a decryption algorithm that 
may be used to decrypt the first data with a plaintext 
^5 version of the first decryption key as derived from the 
respective ACER-contained, encrypted version of said 
first decryption key. 

16. A machine system according to claim 14 wherein said 
on-encrypted other data inclucfes: 

50 (a.3bi) a unique identification of the respective ACER for 
distinguishing the respective ACER from other 
ACER'S within said second data. 

17. A machine system according to claim 16 wherein said 
unique identification of at least one ACER includes a Unique 

55 User Identification signal (UUID) for associating the at least 
one ACER with a respective one of said multiple users. 

18. A machine system according to claim 14 wherein said 
non-encrypted other data includes at least two members of 
the following group: 

60 (a.3bi) a unique identification of the respective ACER for 

distinguishing the respective ACER from other 

ACER'S within said second data; 
(a.3bii) an identification of a decryption algorithm that 

may be used to decrypt the first data with a plaintext 
65 version of the first decryption key as derived from the 

respective ACER-contained, encrypted version of said 

first decryption key; 
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(a.Sbiii) an identificatioD of the first encrypting process 
that was used to produce said first data; 

(a.3biv) a special processing code for specifying special 
processing for the respective ACER; 

(a.3bv) a record format code for specifying a respective 
data format for additional data contained in the respec- 
tive ACER; and 

(a.3bvi) a group identifying code for specifying a group of 
ACER'S or a group of users to which the respective 
ACER or respectively-associated user belongs. 

19. A machine system according to claim 14 wherein said 
non-encrypted other data includes at least five members of 
the following group: 

(a.3bi) a unique identification of the respective ACER for 
distinguishing the respective ACER from other 
ACER'S within said second data; 

(a.3bii) an identification of a decryption algorithm that 
may be used to decrypt the first data with a plaintext 
version of the first decryption key as derived from the 
respective ACER-contained, encrypted version of said 
first decryption key; 

(a.3biii) an identification of the first encrypting process 
that was used to produce said first data; 

(a.3biv) a special processing code for specifying special 
processing for the respective ACER; 

(a.3bv) a record format code for specifying a respective 
data format for additional data contained in the respec- 
tive ACER; and 

(a.3bvi) a group identifying code for specifying a group of 
ACER'S or a group of users to which the respective 
ACER or respectively-associated user belongs. 

20. A madiine system according to claim 1 wherein: 
(a3) said second data contains a plurality of Access- 
Control-Entries Records (ACER's) and each re^cctivc 
ACER includes: 

(a.3a) a first entry containing a respective, encrypted 

version of the first decryption key, and 
(a.3b) a second entry containing encrypted other data. 

21. A machine system according to claim 20 wherein said 
encrypted other data includes at least one member of the 
following group: 

(a.3bi) a unique identification of a user associated with the 
respective ACER, said identification distinguishing the 
respective user firom others of said multiple users; 

(a.3bii) an identification of a decryption algorithm that 
may be used to decrypt the first data with a plaintext 
version of the first decryption key as derived from the 
respective ACER-contained, encrypted version of said 
first decryption key; 

(a3biii) an identification of the first encrypting process 
that was used to produce said first data; 

(a.3biv) a respective, encrypted version of the first 
encryption key; and 

(a.3bv) a respective, encrypted version of another encryp- 
tion or decryption key that is distributable by way of the 
respective ACER. 

22. A machine system according to claim 20 wherein said 
encrypted other data includes at least four members of the 
following group: 

(a.3bi) a unique identification of a user associated with the 
respective ACER, said identification distinguishing the 
respective user from others of said multiple users; 

(a.3bii) an identification of a decryption algorithm that 
may be used to decrypt the first data with a plaintext 
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version of the first decryption key as derived from the 
respective ACER-contained, encrypted version of said 
first decryption key; 

(a.3biii) an identification of the first encrypting process 
that was used to produce said first data; 

(a.3biv) a respective, encrypted version of the first 
encryption key; and 

(a.3bv) a respective, encrypted version of another encryp- 
tion or decryption key that is distributable by way of the 
respective ACER. 

23. A machine system according to claim 1 further com- 
prising: 

(d) second data conveyance means which is operatively 
coupled to the first data conveyance means for convey- 
ing replicas of said first data and said second data to 
and/or away from the first data conveyance means. 

24. A machine system according to claim 23 wherein said 
second data conveyance means includes at least one member 
of the group consisting of: 

(d.l) transportable media; 

(d.2) drive means for reading data from or writing data to 

transportable media; and 
(d.3) I/O means for communicating with other machine 

systems. 

25. The machine system of claim 1 wherein said first 
decryption key is at least 40 bits long. 

26. A machine-implemented method for distributing con- 
fidential information in encrypted form to multiple users, 
said method comprising the steps of: 

(a) conveying to at least one user machine, first data 
representing said encrypted form of the confidential 
information, where said encrypted form of the confi- 
dential information is producible by a first encrypting 
process using a first encryption key; 

(b) conveying to said at least one user machine, second 
data representing an associated label of the first data; 
and 

(c) including within said second data two or more Access- 
Control-Entries Records (ACER's) each containing a 
respective, encrypted version of a first decryption key, 
said first decryption key being a signal that is appli- 
cable to a first decrypting process for decrypting the 
encrypted form of the confidential information and for 
thereby producing a plaintext form of the confidential 
information, 

(c.l) wherein a first of said encrypted versions of the 
first decryption key, which is contained in a respec- 
tive first of said ACER'S, is decipherable by a first 
ACER key, the first ACER key being associated with 
said first ACER, and 

(c.2) wherein a second of said encrypted versions of the 
first decryption key, ^^dlich is contained in a respec- 
tive second of said ACER's, is decipherable by a 
second ACER key, the second ACER key being 
associated with the second ACER, and the second 
ACER key being different from the first ACER key. 

27. A machine-implemented method according to claim 

26 further comprising the step of: 

(d) decrypting one of said ACER-contained encrypted 
versions of the first decryption key by using the cor- 
responding ACER key to thereby produce a plaintext 
version of the first decryption key. 

28. A machine -implemented method according to claim 

27 further comprising the step of: 

(e) decrypting said first data by using said plaintext 
version of the first decryption key. 
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29. A machine-implemeated method according to claim 
28 further comprising the steps of: 

(f) associating each of said multiple users with a respec- 
tive one of said ACER's; and 

(g) upon receipt of a file access request associated with ^ 
one of said multiple users, locating the associated 
ACER and using the encrypted version of the first 
decryption key contained within the located ACER to 
produce said plaintext version of the first decryption 
key. 10 

30. A machine-implemented method according to claim 
26 wherein: 

(c.la) the first ACER key is a first private decryption key 
belonging to a first public/private key pair of a first of 
said users; and 

(c.2a) the second ACER key is a second private decryp- 
tion key belonging to a second public/private key pair 
of a second of said users. 

31. A machine -usable memory storing a multi-user data 
structure comprising: 

(a) a secured file data portion (*FILE DATA* portion) that 
is encrypted by a first encrypting process using a first 
encryption key; and 

(b) a file label portion associated with the secured file data 25 
portion, said file label portion including: 

(b.l) a plurality of Access- Control -Entries Records 
(ACER*s) each containing a respective, encrypted ver- 
sion of a first decryption key, said first decryption key 
being a signal that is applicable to a first decrypting 30 
process for decrypting said *FILE DATA* portion, 
wherein each ACER-contained encrypted version is 
decipherable by an ACER-spedfic key. 

32. A machine-usable memory according to claim 31 
wherein each ACER further includes non-encrypted other 35 
data and the non-encrypted other data contains at least one 
member of the following group: 

(b.li) a unique identification of the respective ACER for 
distinguishing the respective ACER from other 
ACER'S within said file label; 40 

(b.lii) an identification of a decryption algorithm that may 
be used to decrypt the encrypted *DArA* portion with 
a plaintext version of the first decryption key as derived 
from the respective ACER-contained, encrypted ver- 
sion of said first decryption key; 

(b.liii) an identification of the first encrypting process that 
was used to produce said encrypted *DArA* portion; 

(b.liv) a special processing code for specifying special 
processing for the respective ACER; 

(b.lv) a record format code for specifying a respective 
data format for additional data contained in the respec- 
tive ACER; and 

(b.lvi) a group identifying code for specifying a group of 
ACER'S or a group of users to which the respective 55 
ACER or respectively-associated user belongs. 

33. A machine-usable memory, according to claim 31 
wherein the file label portion further includes: 

(b.2) a digital signature covering part of the file label 
portion; and ^ 

(b.3) an extension buffer space not covered by said digital 
signature. 

34. A machine-usable memory according to claim 31 
wherein the file label portion further includes: 

(b.2) a number-of-ACER*s signal representing the num- 65 
ber of activated ACER'S present in the label portion; 
and 
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(b.3) a length-of-ACER*s signal indicating the total extent 
of activated ACER*s present in the label portion. 

35. A machine-usable memory according to claim 31 
wherein the file label portion further inchides: 

(b.2) a length-of-label signal representing the total length 
of the label. 

36. A machine-usable memory according to claim 31 
wherein the file label portion further includes: 

(b.2) a plaintext banner that directs inquirers to a network- 
accessible file for further information respecting the 
attached *FILE DATA*. 

37. A machine-usable memory according to claim 31 
wherein each ACER further includes non-encrypted other 
data and the non-encrypted other data contains at least four 
members of the following group: 

(b.li) a unique identification of the respective ACER for 
distinguishing the respective ACER from other 
ACER'S within said file label; 

(b.lii) an identification of a decryption algorithm that may 
be used to decrypt the encrypted *DArA* portion with 
a plaintext version of the first decryption key as derived 
from the respective ACER-contained, encrypted ver- 
sion of said first decryption key; 

(b.liii) an identification of the first encrypting process that 
was used to produce said encrypted *DArA* portion; 

(b.liv) a special processing code for specifying special 
processing for the respective ACER; 

(b.lv) a record formal code for specifying a respective 
data format for additional data contained in the respec- 
tive ACER; and 

(b.lvi) a group identifying code for specifying a group of 
ACER'S or a group of users to which the respective 
ACER or respectively-associated user belongs. 

38. A machine-usable memory according to claim 31 
wherein the ACER-specific key is a private decryption key 
of a user associated with said ACER. 

39. A machine-usable memory according to claim 31 
wherein each ACER further includes non-encrypted other 
data and the non-encrypted other data contains at least three 
members of the following group: 

(b.li) a unique identification of the respective ACER for 
distinguishing the respective ACER from other 
ACER'S within said file label; 

(b.lii) an identification of a decryption algorithm that may 
be used to decrypt the encrypted *DArA* portion with 
a plaintext version of the first decryption key as derived 
from the respective ACER-contained, encrypted ver- 
sion of said first decryption key; 

(b.liii) an identification of the first encrypting process that 
was used to produce said encrypted *DArA* portion; 

(b.liv) a special processing code for specifying special 
processing for the respective ACER; 

(b.lv) a record format code for specifying a re^ective 
data format for additional data contained in the respec- 
tive ACER; and 

(b.lvi) a group identifying code for specifying a group of 
ACER'S or a group of users to which the respective 
ACER or respectively-associated user belongs; 

and wherein the file label portion further includes: 
(b.2) a digital signature covering part of the file label 
portion; and 

(b.3) an extension buffer space not covered by said 
digital signature. 

40. A machine-usable memory according to claim 31 
wherein each ACER further includes non-encrypted other 
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data and the oon-eacrypted other data contains at least three 
members of the following group: 

(b.li) a unique identification of the respective ACER for 
distinguishing the respective ACER from other 
ACER'S within said file label; 

(b.lii) an identification of a decryption algorithm that may 
be used to decrypt the encrypted *DArA* portion with 
a plaintext version of the first decryption key as derived 
from the respective ACER-contained, encrypted ver- 
sion of said first decryption key; 

(b.liii) an identification of the first encrypting process that 
was used to produce said encrypted ^DATA* portion; 

(b.liv) a special processing code for specifying special 
processing for the respective ACER; 

(b.lv) a record format code for specifying a respective 
data format for additional data contained in the respec- 
tive ACER; and 

(b.lvi) a group identifying code for specifying a group of 
ACER'S or a group of users to which the respective 
ACER or respectively-associated user belongs; 

and wherein the file label portion further includes: 
(b.2) a number-of-ACER*s signal representing the 
number of activated ACER'S present in the label 
portion; and 

(b.3) a length -of- ACER'S signal icdicating the total 
extent of activated ACER's present in the label 
portion. 

41. A machine-implemented file-decrypting method for 
decrypting a multi-user data structure in response to an 
access request associated with one user among a plurality of 
users, 

wherein the multi-user data structure has: 

(1) a secured file data portion (*FILE DATA* portion) 
that is encrypted by a first encrypting process using 
a first encryption key; and 

(2) a file label portion associated with the secured file 
data portion, where the file label portion includes: 
(2.1) a plurality of Access-Control-Eotries Records 

(ACER'S) each containing a re^ective, encrypted 
version of a first decryption key, said first decryp- 
tion key being a signal that is applicable to a first 
decrypting process for decrypting said *FILE 
DATA* portion, wherein each ACER-contained 
encrypted version is decipherable by an ACER- 
specific key, 

said file-decrypting method comprising the steps of: 

(a) locating among said Access-Control-Entrics Records 
(ACER's), an ACER associated with said one user; 

(b) obtaining a private key of the one user; and 

(c) using the obtained key to decrypt the respective, 
encrypted version in the located ACER to thereby 
produce a plaintext version of the first decryption key; 
and 

(d) using the produced plaintext version of the first 
decryption key to decrypt the secured file data portion. 

42. A machine-implemented file-decrypting method 
according to claim 41 where the file label portion includes: 

(2.2) a digital signature covering part of the file label 

portion; and 
said method further comprises the step of: 

(e) using the digital signature to verify that the file label 
portion has not been tampered with in an unautho- 
rized manner before using the file label portion. 

43. A machine-implemented file-decrypting method 
according to claim 41 where the file label portion includes: 
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(2.2) a label-presence verifying field containing code for 

verifying that the label portion is present; and 
said method further comprises the step of: 

(e) using the label-presence verifying field to verify that 
5 the file label is present before proceeding with one or 

more of said steps (a) through (d). 

44. A method for distributing encrypted *FILE DATA* 
signals to a plurality of users and for providing respective 
authorized users among said plurality of users each with 

10 intelligible access to information represented by a plaintext 
version of the encrypted *FILE DATA* signals, 

wherein said *FILE DATA* signals are producible by 
using a first encrypting algorithm in combination with 
a first encryption key to encrypt the plaintext version of 
1^ said *nLE DATA* signals, 

said method comprising the steps of: 

(a) conveying the encrypted *FILE DATA* signals to 
a first data conveyance means; 

(b) defining a companion first decryption algorithm and 
a companion fii^ decryption key that are usable for 
decrypting the conveyed *FILE DATA* signals; 

(c) for each respective authorized user, encrypting the 
companion first decryption key by using a respective 
second encryption algorithm in combination with a 
respective second encryption key to thereby produce 
a respective encrypted version of the companion first 
decryption key, wherein said second encryption key 
is a public key of the respective authorized user, and 
said respective second encryption algorithm is an 
asymmetric algorithm based on paired pubHc and 
private keys; 

(d) for each respective authorized user, conveying the 
respective encrypted veraon to the first conveyance 
means; and 

(e) for each respective authorized \iser, associating at least 
partially by means of the first conveyance means, the 
respective encrypted version of the companion first 
decryption key with the conveyed *nLE DATA* sig- 
nals. 

45. The method of claim 44 further comprising the steps 
of: 

(f) assigning a unique user identification code sequence to 
each re^cctive authorized user; and 

45 (g) conveying the unique user identification code 
sequence of each respective authorized user to the first 
conveyance means; 
wherein said step (e) of associating includes: 

(e.l) associating the conveyed unique user identifica- 
50 tion code sequence of each respective authorized 

user with the user's re^ective encrypted version of 
the compaiuon first decryption key. 

46. A method for reducing possible data leakage due to an 
allegedly compromised user key where the allegedly com- 

55 promised user key is initially usable for gaining intelligible 
access to a file access key, the file access key providing 
intelligible access to an encrypted file, said method com- 
prising the steps of: 

(a) providing a file security label having a plurality of 
60 access control entries records (ACER's), wherein each 
ACER includes a respective encrypted version of the 
file access key, each respective encrypted version of the 
file access key of each ACER being decipherable with 
a respective user key associated with said ACER; 
65 (b) locating among said plurality of access control entries 
records (ACER's), an ACER if any, that is associated 
with said allegedly compromised user key; 
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(c) canceling out the intelligible-access gaining usability 
of the located ACER firom the file label without affect- 
ing such same usability of others of the ACER'S that are 
not associated with said allegedly compromised user 
key. 

47. A key-distribution method for use with an asymmetric 
first encryption/decryption system where the first 
encryption/decryption system uses a first encryption key 
during encryption and the first encryption/decryption system 
uses a different first decryption key during decryption, said 
method comprising the steps of: 

(a) encrypting supplied plaintext data using the first 
encryption key to produce resuhing encrypted data; 

(b) supplying the resulting encrypted data to a data 
conveying means; 

(c) producing plural encrypted versions of the first 
decryption key using a respective plurality of different 
second encryption keys and conveying said plural 
encrypted versions of the first decryption key to the 
data conveying means; 

(d) producing plural encrypted versions of the first 
encryption key using a respective plurality of different 
encrypting keys and further conveying said encrypted 
versions of the first encryption key to said data con- 
veyance means, wherein said plurality of different 
encrypting keys are each respectively part of a respec- 
tive asymmetric second encryption/decryption system; 
and 

(e) associating by means of an associating media, respec- 
tive ones of the encrypted versions of the first encryp- 
tion key and respective ones of the encrypted versions 
of the first decryption key with one another and with 
said encrypted data. 

48. The method of claim 47 further comprising the step of 
selectively conveying the encrypted versions of the first 
encryption key to some but not all authorized users. 

49. A method for selectively enabling multiple users to 
access encrypted replicas of a given file where respective 
first and second ones of the encrypted replicas are stored in 
different first and second locations, said method comprising 
the steps of: 

(a) providing a file label at the first location that permits 
a given user (User_J^J) to intelligibly access the first 
encrypted replica which is located at the first location; 
and 

(b) providing a second file label at the second location that 
blocks the same user (User_#J) from intelligibly 
accessing the second encrypted replica which is located 
at said second location. 
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50. A method for changing the number of authorized users 
that are authorized to intelligibly access an encrypted *FILE 
DATA* portion of a file wherein the file fiirther includes a 
file label portion containing one or more active access 
control entries records (ACER's), said file label portion 
including a number-of-ACER's indicator for defining the 
number of active ACER'S, and each ACER including a 
respective encrypted version a file access key, the file access 
key providing intelligible accessibility to said encrypted 
*FILE DATA* portion, said method comprising the step of: 

(a) altering the number-of-ACER's indicator in the label 
portion to thereby redefine the number of active 
ACER'S. 

51. A method for locating related versions of a secured file 
where the secured file and the related versions each includes 
a *FILE DATA* portion and an associated label portion, the 
label portion having an ordered collection of access control 
entries records (ACER's) including a first ACER, each 
ACER being logically associated with a unique user 
identification, said method comprising the steps of: 

(a) obtaining the user identification associated with the 
first ACER in said collection; and 

(b) using the obtained user identification to locate secured 
other files wherein the first ACER in each secured other 
file is logically associated to the same user identifica- 
tion. 

52. A method for authorizing new users to intelligibly 
access a secured file having an *FILE DATA* portion and 
an associated file label portion where the file label portion 
includes activated ACER'S and the file label portion further 
includes an extension buffer zone for receiving ACER 
add-on requests, said method comprising the steps of: 

(a) including the public key of a requesting user in a 
respective ACER add-on request; 

(b) using the included public key to encrypt a plaintext 
version of a file access key, where the plaintext version 
of a file access key is usable for decrypting the *F1LE 
DATA* portion. 

53. A method of hiding from general viewing the presence 
of one or more ACER*s (Access-Co ntrol-Entries Records) in 
a file label portion containing a plurality of ACER's, said 
method comprising the step of: 

(a) including a special handling code in the respective one 
or more ACER'S whose presence is to be hidden, the 
included special handling code being for instructing 
one or more label-using programs to not display each of 
said one or more specially-handled ACER's. 
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